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SYI'^OPSIS 

The emerging area of Decision Support Systems (DSS) is 
significantly influenced by the ready availability of micro/ 
personal computers and the recent advances in database 
management. The widespread use of spreadsheet analysis has 
involved the managers directly in the decision making process. 
It is expected that the next generation of DSS would make use 
of the sophisticated techniques of Operations Research/ 
Management Science (OR/MS), Such a scenario would integrate 
the user, the display, the interface software, data management 
and model management systems. This would facilitate the best 
use of the analytical capabilities of the decision maker and 
the accurate and fast data retrieval capabilities of the 
computer. Ultimately the modelling activity itself need to 
be supported with an integrated system. This dissertation 
is an attempt in this direction, in the area of optimization 
modelling. 

Optimization modelling using mathematical programs has 
been receiving an increasing attention in the recent years. 
This is due to the fact that many real life problems can be 
easily modelledj they also enjoy a good algorithmic support 
and efficient implementations. However, the support from 
the machine to the modeller has been restricted primarily to 
the numerical solution. The other aspects of modelling such 
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as, formulation, data analysis and solution analysis have 
received only a limited attention. Mostly this has been 
in the form of matrix generators and report writers. Many 
of them are implementation specific and lack generality. 

In this thesis we develop an integrated modelling and 
data management system, LAMP, that attempts to provide the 
modeller, support in the entire life cycle of modelling 
process. Our approach has been to conceptualize an archi- 
tecture that encompasses all the activities of the modelling 
phase in situations using mathematical programming. LAMP is 
designed with a general algebraic notation natural to mathe- 
matical programs. Features like indexing, symbolic represen- 
tation of entities (constraints, variables and objective), 
s3rmbolic summation.& special structures have been implemented. 

The. LAMP has advantages of verifiability, modifiability, document- 
ability and simplicity. The- major advantage of such a 
modelling language has been the independence of problem 
structure and problem data, thereby enabling the modeller, 
the meta-level interface with the problem solving software. 

LAMP attempts to integrate the modelling language with 
the other phases of modelling through the concept of relational 
database management. The input data and the results are 
viewed as a set of normalized relations. This approach 
facilitates an elegant structure that can be used as a 
standard data representation. Incidentally this can serve ; 
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as a neat alternative to the industry standard MPS Format, 

The power of relational database management and standard 
query languages can be exploited to assist the data analysis, 
data validation, solution analysis and report writing phases 
of the modelling with an ease and elegance that far surpass 
the power of matrix generators and report writers. The data 
independence and integrity features permit the structure 
to be implementation independent. Hopefully, such an 
architecture would pave the way for a new generation of 
problem solving systems, in both the area of mathematical 
programming as well as in other areas of management science. 
The ideas are illustrated using an agricultural planning 
model . 

The implementation is based on the problem processing 
software LINDO and UTvIIFY relational data management software 
using SQL query language. 



CHAPTER I 


INTRODUCTION 

1.1 DECISION SUPPORT SYSTEMS i 

The application of computers to managerial problem 
solving has witnessed a considerable growth in the last 
three decades, both in quantitative and qualitative terms. 

The quantitative expansion is readily appreciated through 
the massive investments being made by corporations, in 
hardware as well as software, in terms of office automa- 
tion, computerized planning and control systems and communi- 
cation equipment. The qualitative improvement though subtle, 
is in fact the more important one. The earlier days were 
marked by the dominance of data processing equipment which 
primarily emphasized mechanization of record keeping and 
accounting functions. The second genera-cion saw a shift 
in emphasis from electronic data processing to management 
information system (MIS). The philosoph^;^ of management 
information system laid stress on the use of information 
for decision making. In ad.dition it also saw the emergence 
of models, primarily in the areas of Operations Research/ 
Management Science (OR/MS) to help the managerial decision 
making activity. Optimization techniques with emphasis on 



efficiency were increasingly applied leading to optimal 
decision rules. The early success of this approach did 
contribute substantially to the emergence and growth of 
management science. 

Despite the tremendous growth in computer“relatad 
activities, the field of Management Information System, 
had little significant impact on the style and/or process 
of managerial decision making. This can be traced in 
large part to the lack of proper perspective on the problems 
involved in augmenting the decision making ability of 
management [llS]. The philosophy of decision support 
is primarily intended to overcome this limitation. 

This new approach, generally known as Decision 
Support System (DSS) philosophy, shifts the emphasis from 
the efficiency of decision making to the effectiveness of 
decision making [ 5 _! . To quote Peter Drucker, efficiency 
emphasizes doing things right , while effectiveness 
emphasizes doing, right things. The decision support 
approach recognizes the followings 

(a) difficulty of communicating the utility of sophisti- 
cated Management Science/Operations Research technique 
to practising managers. 

(b) lack of appreciation of the complexities of real 
world by the Management Scientists/Opurations 
Researchers. 


(c) apprehension that an imposed optimal solution may put 

into question, the value of experience, maturity, 

judgement and wisdom gained by real world practice. 

Recognizing these realities the DSS philosophy tries 
to support decision making rather than substitute decision 
makers through the use of models. It also lays considerable 
stress on the involvement of the decision maker directly in 
the decision making process, rather than his indirect involve- 
ment through the management scientists, which often is 
considered to be the esseuice of MIS approach. 

Developments in tv/o distinct areas within the last few 
years have made the DSS approach particularly appropriate [llS] . 
First, there has been considerable technological progress - 
the evolution of computer equipment with substantial power at 
affordable costs, the technology of database, the personal '' 
computer revolution making computing power available at desktop, 
the communication revolution enabling remote access to data 
and resources, the emergence of interactive computing and the 
low cost availability of user-friendly software [ll8j , The 
second development in the last few years has been a conceptual 
one. An understanding of the inherent structure of informa- 
tion systems within organizations is emerging. Also, we are 
adding to our knowledge, the ways in which human beings solve 
problems and the ways in which we can build models that 
capture aspects of their decision making processes. These 
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insights provide us with some important concepts for system 
design [l5l] . 

The progress in these areas have been dramatic, and 
our planning and control systems should reflect the new 
capabilities. We now can build entirely new kinds of systems 
that dynamically involve the manager* s judgement and support 
him with flexible access to data and models. These systems 
are known as Decision Support Systems. 

1.2 OPTIMIZATION MODELLING i 

Most people think of a model as being a small-scale 
version of a large object - a model ship or a model plane. 

The sense in which models are used in Management Science is 
analog ous» hut not quite the same. Ships can be scaled down 
with no material loss of realism in certain important charac- 
teristics. But business systems cannot be scaled down easily. 
We need a representation, which wdll behave similarly. A 
business contains legal, psychological, sociological, engineer- 
ing and other factors and is a very complex affair. It cannot 
be represented in a scaled down form without serious over- 
simplifications. After prolonged experimentation v/ith various 
sorts of representations, it has been found that a mathematical 
model is a useful kind of model of a business enterprise. The 
set of mathematical equations does not bear 'Ony physical 
resemblance to the business enterprise, of course, but the 



equations can be chosen so that the values of variables 
relate to one another in a manner comparable to the relation- 
ships between variables in the organization. If the variables 
in the model have real counterparts, and if the relationships 
between the variables in the model correspond closely to the 
relationships in the real business system, we should be able 
to test the probable effect of charges in the real system 
by making equivalent changes in the model. Evidently, there 
is a great need for care in devising the system of equations 
so that the predicted outcomes are realistic. 

The great advantage of Decision Support Systems is that 
the equations do not need to deal with all the factors at the 
same time and one can ev^ n omit some of them. The manager 
can supply his own estimatr. for some of the parc^rneters based 
on his experience. Conversely, the manager can safely rely 
on his model to carry out the numerical and analy^tical parts 
of the process. The interaction of the manager v/ith the 
model permits the strengths of the computer and the strengths 
of the manager to be brought to bear on the same problem at 
thu s<-me time. The intuitive judgement of the manager, with 
his years of experience of the business system cannot be 
computerized. Similarly, the data storage and retrieval 
capacity of the machine and the calculating power of the 
model using the machine are far beyond the capabilities of 
a manager. Each can contribute to the decision through a 
decision support system [lis]. 
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The use of models in management science is definitely 
not new. However, their application using the decision 
si;ipport approach is relatively new. In fact, this has led 
to a situation, where the discipline of modelling has advanced 
rather slowly while the disciplines concerning the analysis 
and development of techniques to solve such problems have 
grown much faster. It is imperative at this stage to redress 
this imbalance, as has been pointed out by Geoff rioii [76] 
recently. 

The first attempt at modelling in a supportive environ- 
ment, came rather interestingly through the simple spreadsheet 
modelling [23,75,76]. This gave the practising manager, an 
opportunity to get involved in the modelling process directly, 
VJhile the power of spreadsheets is definitely limited, the 
richness of its applications in real life has almost created 
a revolution [49]. In a parallel vein, modelling languages 
like IFPS [80,134] had been steadily in use in restricted 
areas of management like Financial Planning. What is needed 
now is to extend the scope of modelling systems that are 
directly used by managers, to include th^.- capabilities of 
the sophisticated techniques of Operations Research/Management 
Science . 

Among the several techniques of Operations Research/ 
Management Science, optimization models using mathematical 
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programming have been the most extensively used toolS. 
Mathematical programming in general and linear programming 
in particular have the following significant advantages* 

(a) ability to model a wide variety of applications 

(b) availability of tools/techniques to solve reason- 
ably large problems that occur in real life 
situations. 

The early applications of linear programming did evolve 
from simple numerical analysis software into sophisticated 
matrix generators. However, to embed optimization techniques 
within a decision support environment one needs to enlarge the 
scope of such software to the entire life cycle of modelling. 
This alone will allow a true interactive modelling capability 
rather than a mere solution capability. Such an approach will 
create a re-omergence of mathematical programming applications, 
improve modeller productivity, enhance the modeller-manager 
communication and ultimately to a better acceptance of the 
models [76.1. The research reported in this thesis is primarily 
to design a support system for such a situation. Such an 
exercise, it is hoped, will lead to a new generation of 
decision support systems. Moreover the ideas developed would 
be useful for generating fur more general decision support 
systems that may involve many of the techniques of Operations 
Research in an integrated manner. Geoffrion [76] has recently 
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pointed out the heiiefits of such a philosophy, which he 
terms a general modelling framework. 

1.3 OUTLINE OF THE THESIS”. 

Chapter II contains the literature review. First the 
developments in the area of decision support are reviewed. 

This is followed by a review of the literature pertaining to 
problem processors, matrix generators and modelling languages 
for mathematical programming. The capabilities of a number 
of existing matrix generators is contrasted with the 
capabilities of a number of emerging modelling languages. 

The need for a model management system with enhanced capabi- 
lities of data management is established. 

Chapter III outlines the research goals of our modelling 
system LAMP alongv/ith the possible benefits arising out of 
research efforts in this direction. 

Chapter IV covers the various features of the modelling 
language proposed in this thesis. The syntax of the language 
is specified in the form of an EBNF Grammar [9S]. Next 
follows, the features of the language, its capabilities and 
the implementation details. A sample problem illustrating 
the details is also provided. 

In Chapter V the need for an interface between the 
modelling language (s) and problem processor (s) is established. 



A standard in the fom of a set of relations to represent the 
data associated with arbitrary linear programs is proposed. 

Chapter VI demonstrates the use of a standard rela- 
tional database management and a query language to accomplish 
the model manipulation functions. A wide variety of analysis 
and report writing capabilities that is typically needed in 
most modelling situations is accomplished using the query 
language . 

Chapter VII summarizes the conclusions and lists the 
recommendations for further research work in this area. 



CHAPTER II 


LITERATURE SURVEY 


2.1 IHTRDDUCTIOKU 

Decision Support Systems (DSS) represent a broad based 
spectrum of ideas that support the executive decision processes 
with flexible access to data and models [US], The DSS approach 
emphasizes the fact that management involves primarily decision 
making and managers need a direct support, through tools and 
techniques in the decision making activity. The revolution 
in computing power in general and micro-* computing in particular 
has helped in translating this support philosophy into real 
life applications by involvement of the decision maker in the 
modelling processes [22]. In fact decision support systems 
and associated modelling represent a renewed interest in 
Operations Research/Management Science (OR/MS) techniques [32]. 

It is generally observed that optimization represents a 
major application technique in the entire gamut of OR/MS 
techniques. Several studies have established this observation 
[121]. Linear Programming (LP) has enjoyed a widespread 
acceptance, due to ease of use, that is oharacteristic of 
linearity of constraints and objective function. Consequently, 
linear programs involving several thousand of variables and 
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several hundred of constraints have been traditionally solved 
in such diverse industries like Petroleum, Food, Transportation, 
Energy and Service Sector j_176]. Almost all application of 
LP made extensive use of computational facilities leading to 
sevf'ral software products called LP Packages. Applications of 
Nonlinear Programming (NLP) to real world problems are emerging 
only recently. Such systems that lend computational support to 
the solution of mathematical programming problems are usually 
referred to as Problem Processors . They have evolved conside- 
rably in terms of power and cpmploxity in the last four decades. 
The early LP Packages primarily exploited the numerical problem 
solving capability of the digital computer [ 75j . Undoubtedly, 
but for the availability of a digital computer there was no 
possibility of solution. Yet, the numerical analysis is only 
a small part of the overall solution process. Modellers soon 
started looking for support in non-numeric computation as well, 
leading to the early matrix generators. 


Linear programs are expressed in one kind of form for 
human designers or modellers, but in a quite different form for 
computer algorithms. Thus the translation from modeller’s form 
to the algorithmic form is an essential task. Traditionally, 
this task of translation has been divided between human and 
computer through the writing of computer programs known as 
matrix generators A matrix generator is a computer 

program that writes out the algorithmic form i.e., the 
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coefficient matrix of a linear program. Firsts a person reads 
the modeller* s form and writes a matrix generator program for 
it. Then the matrix generator program is executed to produce 
an algorithmic form. Very soon they were found to be inadequate 
and often artificial [68]. As a natural consequence this led 
to the growth of modelling language systems as an alternative 
approach. 

A modelling language system leaves almost all the work 
of translation to the computer. The key concept to such an 
approach is a computer readable modelling language that e3{presses 
a linear program in the same manner that a modeller does. Further, 
it is observed that modelling languages lead to a more reliable 
application of linear programming at a lower overall cost with 
reference to verification, modification, documentation, indepen- 
dence and simplicity aspects [68]. Modelling languages also 
provide a flexible access to modelling by providing support in 
all four stages of modelling viz. formulation, data analysis, 
numerical solution and analysis of results. 

Many of the real life models using linear programming 
need large volumes of data to be processed as part of the solu- 
tion process. The job of managing this large volume data is 
by no means a trivial job. Efforts to integrate data manage- 
ment functions have been attempted elsewhere in an independent 
manner. With the tremendous growth in database technology in 



13 


the recent years we feel that the integration of database 
techniques will go a long way in building powerful model 
management systems. This will be reflected in the philosophy 
of our approach outlined later. 

The evolution through the matrix generators, model 
management tools and the recent intelligent systems for 
mathematical programming [83] is indeed impressive. We take 
stock of these developments in the subsequent sections, which 
provide the background for our work. Our work proposes an 
architecture for the next generation of problem processors, 
that build on the strength of the current problem processors, 

A representative system incorporating this architecture is also 
built,' to demonstrate the power of the designs using this 
architecture, which is the major thrust of this thesis, 

2,2 PROBLEM PROCESSORS 

Solving even small mathematical programming problems 
demands a prohibitive amount of computational effort, if under- 
taken manually. Thus all practical applications of mathematical 
programming require the use of computers. In this section we 
examine the role of the digital computers in this task. The 
task of solving linear programs is greatly facilitated by the 
very efficient linear programming codes that computer manufac- 
turers provide for their computer models. The representative 
ones being IBM»s MPSX [92], CDC»S APEX [4?], BuriX)Ugh»s 
MODELER [33], Honeywell’s MPS [89] etc. Recently independent 
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softwares like LINDO [ 145] , GINO 1 . 114] , GHG l-^ 41] , MINOS [ 128] 
have come into being. In a matter of one or two days, a 
potential user can become familiar with the program instruc™ 
tions thf’.t have to be followeds in order to solve a given prob- 
lem using a specific commerpial code. The ample availability 
of computer codes of good quality is one of the basic reasons 
for the increasing impact of mathematical programming on manage- 
ment decision making. Many of the codes have an extended 
capability to solve integer and limited nonlinear programming 
problems (separable problems, linearly constrained nonlinear 
optimization problems, etc. ) as well. From simple, rigid 
computer programs of the yester-years, the modern linear pro- 
gramming codes have evolved into sophisticated systems with 
modules thit handle input information, provide powerful compu- 
tational algorithms and report the model results. Most of these 
advances have been made possible by developments in software 
and hardware technology as well as break- throi:»ghs in mathema- 
tical programming theory. The continual improvement in compu- 
tational capabilities of mrithematical programming codes is in 
reducing running times and computational costs, to facilitate 
solutions of larger problems 'Ond to extend the capabilities to 
more general non linear, discrete optimization. In the next 
sub-section we will take stock of the basic features common to 
all good current-day systems emphasizing the important concepts. 
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2«2.1 Basic Features 

The basic features can be broadly classified intos 

a) Input Specifications 

b) Solution Techniques 

c) Output Specifications 

a) Input Specifications o 

The first task when solving a linear programming model 
using a computer code is the specification of model structure 
and the input of the corresponding values of the parameters. 
The important elements, the user has to specify ares 

. Number of the decision variables, constraint (s) , 
objective function(s), right hand side(s) 

. Numerical values of the cost coefficients, matrix 
coefficients and right hand sides 

, Nature of the constraint relationship 

. Free and bounded variables 

. Nature of the optimization 

. Title of the problem. 

To facilitate easy and meaningful analysis/retrieval, ^ 
symbolic identification of variables and constraints through 
names (typically of eight characters length) are provided. 
Typically only non- zero coefficients need to be input. Several 
small systems allow free-form input e.g., MPOS [46], Many of 
the codes have evolved over the years, a standard called MPS 
format, originally used by IBM»s MPSX [92], This standard 
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has become archaic and we will propose an alternate elegant 
relational format, later in this thesis. 

Input specifications also include several summary 
results of the data to help the user, undertake checks for 
consistency; t 3 rpical examples being » 

. Row, column count 

. Matrix density (percentage of nonzero coefficients) 

. No, of nonzero elements in each row and each column 

. Values of the smallest and largest element in the 
coefficient matrix, right hand side (s), objective 
function (s) 

. Print-out of equations in expanded form 

. Picture of the full coefficient matrix or a condensed 
form of the coefficient matrix. 

Sometimes, input data need to be scaled. The* simultane- 
ous presence of both large and small numbers in the matrix of 
coefficients should be avoided whenever possible because it 
tends to create problems of numerical instability. This typi- 
cally can be avoided by changing the unit of measure of a given 
variable, say from kg to 1000 *s of kg. 

Later in this chapter we will see further evolution of 
input specifications into full fledged software systems known 
as matrix generators. 
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b) Solution Techniques ^ 

There has been considerable concern in the development 
of problem processohs to reduce the computational time required 
to solve programming problems, by improving the techniques used 
in the optimization stage of the problem. This has been accom- 
plished primarily by refinements in the matrix- inversion pro- 
cedures using triangularization; representation using sparse 
matrix tectinology; path selection criterion by allowing multi- 
ple pricing of several columns to be considered as possible 
incoming variables,* use of more efficient pre-solution techni- 
ques by providing crashing options to be used in order to obtain 
an initial feasible solution or by permitting the user to specify 
initial basis. To avoid the presence and/or groi/fth of numerical 
errors, most codes use original values of the coefficient matrix 
to rej.nvert the basis periodically. ' This process maintains 
accuracy. The frequency of reinversion can be user specified. 

Also the user is allowed to specify feasibility tolerances that 
are designed to check whether or not the values of non- basic 
variables and the reduced cost of the basic variables are zero. 
There are also pivot renection tolerances that prevent coefficient 
very close to zero from becoming a pivot element in a simplex 
iteration. If necessary the systems allow high precision arith- 
metic (generally double precision) to be specified by the user 
to decrease the computational errors. In essence, the systems ; 
allow control of the solution process by the user in a detailed 


way. 
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c) Output Specifications s 

T 3 ^ical output information provided by standard commercial 
codes includes! 

Optimum value of the objective function and optimal 
values of the decision variables 

. Slacks/Surpluscs in the constraints 

. Shadow prices for the constraints 

. Reduced costs for the decision variables 

. Ranges on the coefficients of the right hand side 

, Ranges on the cost coefficients 

. Value transitions resulting from changes in right 
hand side/cost coefficients 

. Sensitivity and Parametric Analysis. 

Occasionally some of the codes provide summary results 
for reporting to management directly. Others provide a report 
writer program that can be user written and appended to the 
system for report generation, ¥e will review some of the 
capabilities in our discussion of matrix generators in the 
next section. 

2*2.2 Current Trends ? 

The current trends in the evolution of problem processor 
include development of model management system (discussed later 
in Section 2.4); improved sophistication in their ability 
to solve nonlinear and integer programming problem, reviewed 
in [175]; porting the software to micro computers resulting 
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in a rich collection of micro based software for mathematical 
program, reviewed in [148, 149], adding gr^hic support, 
reviewed in [l75] , adding explanation capability to linear 
programming packages [ S3] . Spurred by the spread-sheet 
revolution [ 23] , planning languages are being increasingly 
used b 3 ^ modellers. Extending optimization capabilities to 
planning languages is being explored rather recently. IFPS/ 
Optimum [80 ], VINO [49] represent two philosophies in this 
direction. 

2.3 matrix GENERATORS J 

As mentioned previously, a matrix generator is a computer 
program that writes out the algorithmic form i.e., the coeffi- 
cient matrix of a linear program, A number of matrix generator 
and report writer systems which we term as matrix generators 
essentially use a standard mathematical programming processor. 
These systems are quite significant for any organization that 
uses mathematical programming (MP) as a serious modelling tool. 
These systems include matrix-generator (MG) programs and 
report-writer (RW) programs whioh may be written in high-level 
computer programming languages viz. FORTRAN, ADGOL, PL/l or in 
a speoial-purpose matrix generation and report v/riting language. 
In suoh a system, first the matrix-generator progr^mn reads and 
prooesses the "PROuLEM DATA " presented in the form of sets of 
tabulated data to produce a card image of INPUT FILE ; then 
the solver or optimizer generates solution values j finally the 
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report-writer program e3ctracts relevant information and 
presents in a desired format. The card image INPUT FILE 
contains row names that are coded by suitable text expressions y 
column names that are also coded by appropriate text expres- 
sionsj the coefficients of the problem matrixj the RHS aright 
hand side), BOUNDS and RANGES information*, some information 
concerning starting basis. The report-writer program generates 
the specific information from the solution values obtained by 
the optimizer and presents the same information in a suitably 
tabulated format. The report-writer program usually i’efers 
the "PROBLEM DATA" from the 'INPUT FILE" and may also carry 
out some arithmetic operations on the solution values to generate 
desired information. 

The most prominent among a number of matrix generator 
and report writer systems are* 

MODELER (Model Development Language and Report Writer) 

. developed in 1980 by Burroughs Corporation [33]. 

MaGen (Matrix Generator) 

. developed in 1977 by Haverly systems Inc. [86]- 
MGRW (Matrix Generator and Report Writer) 

, developed in 1972 by IBM World Trade Corporation [91]. 
GAI#IA (Version 3.4) 

. developed in 1977 by Sperry Univac Computer System [154]. 
DaTAFORM (ms-111 Version) 

. developed in 1975 by Ketron Inc. (l08] . 
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APEX (Version - III) 

. developed in 1979 by Control Data Corporation L 9-7 ] . 

These systems coramonl^r incorporate at least the follow- 
ing features; 

. input of problem data in a tabular form 

. construction of row and column names by name 
expression 

. use of constants or arithmetic expressions to 

specify the matrix, RHS, BOUND, etc., coefficient's 
by suitable row or column generator clause (procedure) 

. access to the solution llle to obtain solution 
values, reduced costs, ranges, etc. 

. formatted and printed tabular information. 

Current matrix generators incorporate their own MG 
languages in which the programs are written. They commonly 
presume a sequence of four forms; modeller’s form, MG form. 
Standard (MPS) algorithmic form, and specialized algorithmic 
form. These languages incorporate loops, assignments, trans- 
fer of control or other executable statements in describing 
the computer program. 

Matrix generation is certainly a great advance over 
translation by human labour alone, particularly for very 
large linear programs. However, they suffer from potential 
difficulties viz. verifiability, modifiability and documenta- 
bility which are aggravated by introduction of matrix-generator 

Csfi. 

form,^ The associated drawbacks of matrix generators ares 
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Verif lability g This being the major consideration in a 
linear program, refers to determining whether modeller*' s 
form correctly represents the reality and also determining 
whether the algorithmic form is a correct translation of the 
modeller’s form. The verification of matrix-generator program 
necessitates program debugging at the cost of human time and 
computer time. ' , • 

Mo dif lability s This relates to determination of new modeller’s 
form corresponding to any change in real life problem situation 
and translating the new modeller’s form to a new algorithmic 
form. Thus in the case of matrix generators, any modification 
essentially amounts to revising matrix-generator computer 
program which again aggravates the task of program debugging. 

Documentability i This relates to maintaining of all relevant 
information pertaining to different forms and their relation- 
ship. The matrix generator requires additionally, documenta- 
tion of matrix-generator program which is fairly lengthy, 
time consuming and unpopular with programmers; yet inadequate 
documentation can eventually make it difficult to use or 
change a program. 

The matrix generators also have drawbacks related to 


the following areass 
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Independence c The weakness of matrix generators lies in their 
involvement v/ith the algorithmic form. The conceptual binding 
with particular algorithmic form imposes restrictions with 
regard to features viz. naming of LP components, ordering of 
coefficients and representation of special constraints. This 
in turn necessitates modeller* s familiarity with particular 
algorithmic form which could be avoided only at some additional 
cost. 

simplicity ! The final drawback of matrix generation stems 
from the basic approach of translation task i.e,, introduction 
of intermediate MG form. This additional form increases the 
modeller’s burden and complicates the conceptually simple job 
of translation of modeller’s form to algorithmic form. 

Further, the majority of matrix generators are more 
influenced by the algorithmic form i.e,, D'lPS form. Therefore, 
the modellers using these matrix generators have to follow 
various conventions and restrictions of matrix-generator 
data format and of MPS form at the cost of extra v\Prk and 
complication. These above mentioned difficulties lead to 
the development of modelling languages described in next 
sectionfe^. 
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2.4 MODELLING LANGUAGES : 

Modelling Languages (ML) as mentioned earlier are 
natural evolution from the matrix generators. They are 
designed to provide a superior support in all the phases 
of modelling. In this system, the modeller first creates a 
symbolic modelling language description of the mathematical 
program of interest and then a computer system reads the 
above symbolic description along with the corresponding 
explicit set and parameter data to translate it to the desir- 
ed algorithmic form. Thus a modelling language system serves 
to divide the work of translation between a person and com- 
puter with greater portion of work shared by computer as 
compared to matrix generators. ML-like systems for linear 
programming have mostly been developed since late seventies. 

The more sophisticated of these languages incorporate some 
kind of symbolic indexing, in order to conveniently represent 
fairly large models. The major systems employing modelling 
languages’ features are ALPS [170], GAI^IS [lQ5] , LMC [L24 ] , 

LP MODEL [103], MAGIC [52], MGG [147], UIMP [l67 ] , ML [68], 

SM [75 ] . They are further outlined below. 

ALPS (Advanced Linear Programming System) s 

ALPS is an easy to use mathematical programming package 
developed in 1977 by United Computing Systems, Inc,, Washington, 
USA. The modelling language uses "FOR*'' loop statements to 
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define constraints. The language notation is fully algebraic 
and it incorporates general linear e3<pressions v/ith limited 
variety of indexed sums. The data description is based on 
symbolic parameters only and subscripted identifiers are 
used for model -component names. It allows for coefficients 
to be given in a row-wise organization. Special constraints 
such as simple bounds can be described like other constraints. 
The model description is independent of explicit data. Further 
details regarding major features are available in [158], 

GAMS (General Algebraic Modelling System I s 

A general algebraic modelling language package was 
developed at the World Bank Development Research Center j 
Washington, USA. It has been in extensive use since 1979- 
The modelling language uses assignment statements. The lan- 
guage notation is algebraic with some exceptions and it 
incorporates general linear expressions and indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component 
names. It allows for coefficients to be given in a row-wise 
organization. Special constraints such as simple bounds can 
be described in a special manner. The model description is 
not independent of explicit data. Further details regarding 
major features are available in [l2l] . 
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LMC (Linear Modelling Capability)^ 

A subsystem of Conversational Modelling Language (CML) 
was developed at Yale University Institute for Social and 
Policy Studies Center, Connecticut, USA. It has been in use 
since 1977- The modelling language uses assignment statements. 
The language notations are English like rather than algebraic 
and it incorporates general linear expressions and indexed 
sums. The data description is based on symbolic sets and 
parameters and subscripted identifiers are used for model 
component names. It allows for coefficients to be given in 
a row-wise organization. Special constraints such as simple 
bounds can be described like other constraints. The model 
description is independent of explicit data. Further details 
regarding major features can be found in [124], 

LPMODEL (Linear Programming Modelling Language) 

A modelling language system for linear p3xigrams was 
devoloptd at IBM Israel Scientific Center, Haifa, Israel. It 
has been in use since 1980. The language notation is alge- 
braic with moderate alteration (e.g. , "SUI-l" for summation 
notation) and it incorporates general linear e^pDressions and 
limited indexed sums. The data description is based on 
symbolic sets and parameters implicitly defined and concate- 
nated identifiers are used for model component names. It 
allows for coefficients to be given in a row-wiso organization. 
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The model description is independent of explicit data. Further 
details regarding major features are available in [ 103 ]. 

MAGIC (Matrix Generator Instruction Convertor) s 

A modelling language package was developed at University 
of Edinburgh Scotland. It has been in use since 1982. The 
modelling language uses "FOR" loop statements to define 
constraints. The language notation is fully algebraic and 
it incorporates limited linear expressions and general 
indexed sms. The data description is based on symbolic 
parameters only and subscripted identifiers are used for 
model component names. It allows for coefficients to be 
given in a row-wise organization. Special constraints such 
as simple bounds can be described like other constraints and 
ranges can be described in a special manner. The model des- 
cription is not independent of explicit data. Further details 
regarding major features of this system are available in [52]. 

MGG (Matrix Generator Generator) ^ 

A modelling language package was developed by Scicon 
Computer Services Ltd. , England. It has been in use since 
1975. The language notation is fully algebraic and it incor- 
porates very limited linear expressions and indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component names. 
It allows for coefficients to be given in a row- wise organiza- 
tion. Special constraints such as simple bounds and 
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generalized upper bounds along with ranges can be described 
in a special manner, '^he model description is independent 
of e:5<plicit data. Further details regarding major features 
can be found in [l46 ] , 

UII^IP (User Interface for Mathematical Programs) s 

A mathematical programming package was developed by 
UNICOM Consultants Ltd. j Surrey, England. It has been in use 
since 1976. The modelling language uses loop, assignment 
statements and transfer of control to define constraints. 

The language notation is fully algebraic and it incorporates 
very limited linear ejqjressions and general indexed sums. 

The data description is based on symbolic sets and parameters 
and subscripted identifiers are used for model component 
names. It allows for coefficients to be given in a row-wise 
or column wise organization. Special constraints such as 
simple bounds and ranges can be described in a special manner. 

The model parameters may be independent of explicit data. 

Further details regarding major features are available in [6l]_,[6^ 

JML (A Prototype Modelling Language) i 

XML is a hypothetical modelling language based on the 
sort of modeller’s form. It has been developed by Fourer at 
MIT, Cambridge, USA. The modelling language system has five 
major sections^ sets, parameters, variables, objective and 
constraints. The language notation is algebraic with moderate 
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alteration and it incorporates both indexing and arithmetic 
expression. The data description is based on symbolic sets 
and parameters and subscripted identifiers are used for model 
component names. It allows for coefficients to be given in 
a row-wise organization. It is syntactically and semantically 
simpler. A detailed specification of the modelling language 
system is available as technical report by Fourer [67]jC^^* 

SM (structured Modeling ) s 

SM is being developed at Western Management Science 
Institute, University of Celifornia, Los Angeles, USA. It 
endeavours to provide a formal mathematical frame work, 
language and computer based environment for conceiving, 
representing and manipulating a wide variety of models. The 
frame work uses attributed acyclic graphs, set partitions 
and hierarchies to represent the semantic as well as mathe- 
matical structure of a model. The language is computer 
executable and yet natural for novice users. The computer 
based environment is evolving. Further details regarding 
salient features can be found in [76]. 

Other systems like LINDO [1^5], MPOS [46] do have 
the flavour of modelling language even though they are pri- 
marily problem processing systems. 

Critical examination of the modelling systems reveals 


the followings all of them use modelling languages that 
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resemble modeller ’’s form to some degree and do not involve 
programming, though traces of programming languages forms 
can be found especially in ALPS and UlliP. UIMP end MGG use 
r^PS naming schemes i,e., eight characters- long names for 
their entities vrhereas other systems do not have such 
restrictions. All of them permit a constraint-wise (row-wise) 
organization, except UIMP, which allows column-wise organiza- 
tion also. All except LPMODEL use subscripted identifiers 
for naming model components; LPMODEL usei^oncatenated identi- 
fiers of unrestricted length for the similar purpose. ALPS 
permits quadratic objective. MA.GIC, MGG, UlldP and ALPS 
support discrete (integer) optimization model as well, ALPS, 
MGG and UIMP ar-^i available as commercial products £6^. 

As a group, the greatest strength of these systems is 
their ability to raise the productivity of optimization 
applications. The serious v/eakness of most of these systems 
is that they are wedded to one particifLar modelling paradigm 
and lack generality to encompass most of the other modelling 
paradigms developed in OR/MS. They also lack integrated 
facilities for query and immediate expression evaluation. 

The above observations match with the aims of structured 
modelling (SM) and suggest for the need of an appropriate 
system providing synthesis of model management, data manage- 
ment and associated interface* which is the focus of this 


thesis. 
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2.5 data MANA1EMENT5 
2.5.1 Intro due ti p no 

Integrating several sets of data needed by several 
applications and sharing the data resource for simultaneous 
access by several authorized users has been the dream of 
information scientists. This has been made possible with 
the technological growth of computer storage devices capable 
of storing large volumes of data at a lesser cost, in the 
recent years. This is generally termed the technology of 
database. A modem definition of database is a set of 
structured data stored on the computer accessible media that 
satisfies the needs of several users simultaneously, in a 
selective manner yet in a reasonable time frame. In order to 
effectively manage such a database, a sophisticated software 
is generally needed. Such a software is generally termed a 
database management system (DBMS) . Basically a DBMS provides 
the means of organizing data on peripheral storage devices 
and retrieval procedures necessary for internal processing 
of the stored data. The user first describes the structure 
of the data and the te’sks in abstract terms and leaves the 
job of determining the best operating mode to the database 
management system. The database structure is described at 
the conceptual level by a logical schema which provides a 
view of the data to the user. At the internal level the 


structure is specified by a physical schema . Usually the 
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structure is specified to the DBMS using a data definition 
language (DDL); the manipulation of the data stored in the 
database is specified through a data manipiiLation language 
(DML) . The foundation for the structure, however, is the 
notion of a data model described in the next section. 

2.5.2 Data Mpd ell; 

The data model is a structured tool used to londerstand 
and interpret the real world. In order to facilitate communi- 
cation, it is useful to regroup the real world objects with 
vifhich we are interested, into homogeneous classes. A data 
model allows one to define relationships which may exist ‘ • 
between different classes of objects. Reflecting different 
views of the relationships amongst the classes of objects 
several data models have been proposed in literature. Of 
these, there are three prominent data models' viz. the hierar- 
chical model, the network mndel and the relational model 
which evolved over the last decade. Using hierarchical 
approach, conceptual model is viewed as a tree graph where 
nodes represent classes of objects and branches represent 
association between two classes. Hierarchical graphs have 
a root and the nodes emanating from root are labelled as 
sons, grandsons s etc, of the root. Using the network approach, 
the conceptual model is viewed as an ordinary graph where 
nodes represent classes of objects and arcs represent associa- 
tion between tvro classes. The network model differs from 
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hierarchical model in that there is no hierarchical limita- 
tions on association. An introductory description of major 
data models is available in DBMS texts 150,16-'^ 9 166 J* The 
widely used hierarchical model based system has been the 
IBM’s IMS (Information Management Systems). The CODASYL 
(Conference on Data Systems Languages) Committee’s recommen- 
dations were based on a Network Model. Consequently a 
number of implementations based on network approach were 
m.ade available in the last decade by several main frame/raini- 
computer manufacturers including IDS [ 40 ] from General 
Electric, DBMS-10 [57] from Digital Equipment Corporation. 
The growing importance of the relational model in the recent 
past suggests that it is likely that the models in the future 
will be predominantly relational (due to reasons elaborated 
in the next section) . 

2.5.3 Relational Data Model s 

The relational data model views the logical schema as 
tables having rows and columns, where each row represents a 
record and columns represent various attributes (fields) 
related with the object. The tabular arrangement of data is 
an elegant representation. This model is based on the 
feature of a mathematical relation which is a set of tuples 
having tuple elements as attributes of the object. The 
mathematical foundation of relational data models permits 
elegant and concise definition and deduction of thoir 
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properties [38]. The relational concept was first applied 
through AOV (attribute, object, value) theory along with an 
algebraic theory of data proposed by Childs [39], about 1968. 
Later around 1970 Codd [43] proposed the relational data 
model concept based on^notion of relation. Being conceptually 
simple, the basic relational model had a tremendous impact 
on database management in general and on data models in 
particular. Because of the elegance of the structure and 
the mathematical foundations of the theory of relations, the 
relational model has become the main sta^/ of research and 
development in the database area. The relational data model 
is claimed to be superior to other data models. However., 
subjective this observation be, the relational approach has 
definitely achieved a great goal_^-«f bringing together the 
practitioners v/ho implement systems and researchers who 
conCt,ptualize them. The various prototype and commercial 
DBMS that implement relational approach include System 
R [9], INGRES [162]. Consequently we concentrate only on 
relational data model in our thesis. 

2.5.4 Query Languages '^ 

Data Manipulation Languages (DML) that allow manipulation 
of data stored in database are generally known as query lan- 
guages. They are non-procedural compared to the procedural 

nature of conventional programming languages like PASCAL and 

com mn Oil 

FORTRAN. They may have features of Twrapjfr - programming languages 
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such as assignments, iterative loops and conditional state- 
ments permitting one to refer data as well as to ^ecify some 
manipulation functions such as insertion, deletion, updation 
and query. Since relational data models are based on 
relations (i.e., set oriented concept), they naturally lend 
themselves to specification operations. The query languages 
use specification operations which may be binary (e.g., sum, 
product, difference and join) or unary (e.g. , selection, 
projection). The salient feature of the query languages is 
their ability to define a new relation based on the existing 
relations using relational algebra or similar (relational 
calculus) type of operations. The new relation is usually 
made available for use as a picture (snapshot) or as a view 
which is an extension of schema. These query languages can 
be classified as* 

(i) Predicate Calculus Language having origin in relational 
calculus concept end based on assertions over a set of tuples 
of a relation (e.g., QUEL [87], ALPHA [ A-4] ) . 

(ii) Display Oriented Language where user is required to 
fill in blanks on a CRT display to formulate a query (e.g. 

QBE [180]). 

(iii) Algebraic Lang^jage or Mapping Oriented Language which 
is based on operations having relations as operands (e.g., 

SQL [55]). 
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Further 5 the query language enables the desired informa- 
tion to be extracted in a relational format by successive 
application of binary operators (e.g. , sum, product, carte- 
sian product, difference and join) or unary operators (e.g., 
complement, selection and projection) on stored database 
relations, treating them as operands. Various query languages 
developed using relational data model concept are QUEL (INGRES) 
[87], QBE [2 80], SEQUEL [29], SQL [95]. They are briefly 
outlined below. 

QUEL, a language based on relational calculus was developed 
for INGRES relational system at University of California, Berkeley 

QBE (Query-By-Example), a display oriented query language 
defined by Zloof [180] which runs on INGRES. 

SEQUEL (structured English Query Language) is the modification 
of language SQUARE developed by BOYCE. The modified language 
was developed for System R. 

SQL (Structured Query Language) is the modified version of 
SEQUEL. It is an English-keyword, set- oriented relational 
data language. It has been implemented in System R DBMS. It 
is based on the concept of mapping operation. 
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2.6 CONCLUSIONS! 

The survey of literature does indicate the desirability 
of building model management systems that integrate data 
management aspects as well. Such systems alongwith a problem 
processor will provide support to a modeller in the entire 
life cycle of the modelling process, and not just in the 
numerical solution of the problem. In our view, numerical 
solution of the linear program constitute but a small, -though 
significant, part of the modelling activity. Hence the 
widening of the support to the model builder is likely to be 
of major significance in the modelling research. The work 
reported in this dissertation develops this thesis further 
in the form of an architecture for modelling support and a 
representative system using this architecture. 



CHAPTER III 


MODELLING SYSTEM LAMP 

3.1 INTRODUCTION- 

Optimization modelling has witnessed an impressive 
growth and evolution, as indicated by the literature surveyed in 
the last chapter. In spite of such advances, optimization has 
not received a widespread acceptance, which it rightly deserves. 
Possibly it is due to some of the problems listed below, as 
identified by Geoffrion in [ 76] . These suggest some desirable 
features for a new generation of optimization modelling systems, 
which is the major thrust of this thesis. 

One of the major problems in the acceptance of optimiza- 
tion modelling is the low productivity as perceived by the 
users. It is contributed by different representations - a 
natural representation suitable for managerial communication, 
a modeller* s form for the analytic use by the OR/MS professional 
and an algorithmic form that is computer executable. Such multi- - 
pie representations demand too many different skills to complete 
even small projects. Matrix generators and the modelling Ian- 
guages partly solve this problem by providing convenient auto- 
matic translation from one form to the other . Another factor 
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contributing to low productivity is the labourious task of 
interfacing models with problem solvers. The commonly used 
MPS Standard [92] for linear programming is ancient and is 
not suitable for modern systems. Finally the available modelling 
systems cater just to one or two phases of the total life cycle 
of modelling such as input data translation and algorithmic 
solution. The phases left out are - requirement design, test- 
ing, revising, maintaining, documenting, explaining, analyzing, 
reporting and evolving the models. Typically such low producti- 
vity leads to poor managerial acceptability. Luckily a number 
of new opportunities, that are being created are potentially 
useful in mitigating many of the problems mentioned above. The 
prominent among them areJ 

(a) Desk top computing revolution - this offers a plethora 
of possibilities for optimization modelling in a more 
productive manner and in ways that are acceptable to 
managers . 

(b) Progress in database systems - data management is an 
important activity in most optimization models as most ?•£«. 
real life applications tend to be large. Managing such 
large data manually is a hopelessly difficult job. 

(c) Popularity of spreadsheet modelling - this had enabled the 
managers to get directly involved in modelling, may be 
inadvertently as pointed out by Bodily [23], thereby 
removing the first block in acceptability of models by 
the managers. 
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The problems and opportunities enumerated above 
suggest that the evolution of problem processors through 
matrix generators and modelling languages must go several 
steps further in the form of new generation of modelling 
systems with the following features?. 

(a) independence of model representation and model 
solution with general interface standards to facilitate 
the integration of a variety of solvers. 

(b) extending the scope of the computational support to 
the modeller in all aspects of modelling. 

(c) integrated data management and adhoc query facilities. 

Keeping in view the points cited above we decided on a 
set of goals for our research, outlined in the next section. 

3.2 RESEARCH GOALS? 

The desirable features of a modelling system, as out- 
lined earlier, represent a possible architecture for a new 
generation of systems that are likely to influence optimization 
modelling in a significant manner. In order to demonstrate 
oirr thesis we will set out to build an experimental system, here- 
inafter ' referred to as LAMP, incorporating this architecture 
and illustrate through detailed examples the advantages that 
are likely to accrue arising out of such a point of view. No 
attempt is being made to develop a full fledged software of 
the kind that is readily usable. We feel that such an effort 
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calls for an altogether different effort and skill and may 
even be premature at this stage. We need a translation 
system i.e., a modelling language subsystem to translate 
the modeller’s form into an algorithmic form. The modeller’s 
form must bo so chosen that it is communicable to the people, 
not necessarily to OR/MS professional, yet easy enoxjgh for 
translation. Most of the modelling I'^nguages like G.AJ4S [l2l] , 
LPMODEL [ 103 ], XML [66] are still evolving at this stage and 
aim at developing them into powerful and independent syscems 
of commercial/professional quality software. Since our pur- 
pose is modest and purely of an experimental interest, we 
plfm to build a system that is small, elegant and yet of 
reasonable power. Having built a modelling language we 
would like to interface it with an independent solver 
LINDO [ 145 ] that has been in use at Indian Institute of 
Technology, Kanp\ir for the past few years with a good amount 
of reliability. We do need an interface standard. We are 
not happy with MPS Standard [ 92] which is not well suited for 
query and integration with data management. It appears that 
an alternate view using simple normalized relations, of the 
input and output data -of a linear program would simultaneously 
meet the twin purpose of an elegant interface stJaidard as well 
as a convenient link to the data management function, 
expend the scope of xho system to include data management 
function, we feel that it will be advantageous to use the 
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well developed technology of data management and query 
languages to do the entire "what™ if" analysis and report 
writing. So we plan to interface our system to an elegant, 
yet powerful DBMS software, viz. UNIFY [368] using yet another 
query language SQL [95] which is one of the popular members 
of its kind. Another simple reason for using this system 
is its availability at IIT Kanpur. Effort will be taken to 
ensure that the concepts being demonstrated are independent 
of the products that are likely to be used i.e., LINDO, UNIFY - 
or SQL, so that they remain sufficiently general. Ultimately 
a3.1 the units would have been integrated so that the support 
provided, enables the modeller to conduct a truly interactive 
modelling and that the support spans the entire life cycle of 
the modelling process. To summarize, the research goals ares 

(a) Develop a simple yet powerful m.odelling language that 
translates the modeller's form into an algorithmic 
form. 

(b) Develop an interface standard between model language 
system and problem processor system (an alternate to 
MPS System [92]). 

(c) Incorporate data management capabilities using the 
ideas of relational data management. 

(d) Study the use of general puipose querry languages to 
edit, modify and conduct "what- if" analysis of the 
models.' 
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(e) To maintain a modu].arity of the system so that they 
can be evolvable, communicable, maintainable and 
document able. 

3.3 RESEARCH BERTEFITSS 

¥e foresee a tremendous demand for a ne'W generation 
of modelling systems with the architecture outlined earlier. 
Demonstrating a system built on such architecture is likely 
to vindicate our viei^/point that such architecture has 
attractive advantages over the current generation of systems. 
Such a viewpoint is likely to overcome the major problem of 
poor acceptance by user. Specifically, the research tasks 
mentioned oculier are likely to lead to the follov/ing benefits. 

Task (a) outlines yet another modelling language which 
in no way can be claimed to be very superior to man^;" of the 
e3<perimental languages like LPMODEL [^^3] , GAMS il05] , XliL [ 661 , 

It can nevertheless be said that none of the e^qjerimcntal ones 
have a fully satisfactory representation of modellers form 
even with respect to linear programming. liVhat is ultimately 
needed is 'a language that can represent far more general 
models. So any addition can only be welcome at this stage. 

What is significant is that a more general structure of the 
modelling language v/ould evolve with man 3 ?- more such experiments. 
In future it is anticipated that with the availability of 
program generators [lOO] , generalized parsers [ 2 ] , compiler- 



44 


compilers, experimenting with newer languages is likely to 
be less expensive. It may be noted here that the modelling 
language being developed would take advantage of the fact that 
many of the data that goes into optimization models in fact 
comes from corporate databases. These are by themselves 
expected to be relational in futirre and the future modelling 
languages woiiLd significantly benefit from such an observation. 

Task (b) would enable the unbundling of the problem 
processor from the modelling languages, matrix generators and 
the report writers. In fact many of the modelling systems are 
built around specific problem solvers and such unbundling vrould 
lead to a happy marriage of powerful problem processors and 
user friendly modelling languages. 

Task (c) would greatly facilitate in the job of having to 
muddle through the volume of data that is typical of most opti- 
mization models. Use of relational data management provides the 
dual advantages of using the ideas of the well developed tech- 
nology of database as well as an ability to maintain an inde- 
pendence between problem processor, modelling language and 
data management system. 

Task (d) would herald an era of trully interactive 
modelling which would significantly affect both the modelling 
process and its ultimate acceptance by the user. 
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Task (e) would provide for an evolution capability of 
the model management system. It is definitely likely that 
each of the sub modules would undergo significant advances 
in the coming years due to the developments in conceptual 
mathematics, program generators, query languages, visual 
editors and the user interfaces, ’rfe have already outlined 
the possible impact on modelling language design due to deve- 
lopments in the area of program-generation. Developments in 
conceptual mathematics would improve the quality of problem 
processors. The emerging ellipsoid algorithm [84] and 
Karmarkar’ s implementation [lOl] may totally change the 
way linear programs will be solved in future. The future 
query languages would enable a far superior "what-if " analysis 
than what is possible today. Advances in visual editors and 
other graphic interfaces may give the modeller an unprecedented 
interactive modelling capability. Possibly iii future an 
intelligent system providing explanation capability could be 
integrated with the system. In essence, the modxfLarity enables 
the user an option of combining the advantages of developments 
in each of the areas without tying him down to any particular 
system. 



CHAPTER IV 


MODELLING LANGUAGE FEATURES OF LAMP 

4,1 INTRODUCTION? 

The previous chapter has outlined the broad objectives 
in the development of a modelling system LAMP at IIT, Kanpur. 

As set out in the earlier chapters the first task is to 
build a modelling language that translates the modeller'' s 
form into an algorithmic form. We first take stock of the 
relative strengths and weaknesses of the earlier systems 
outlined in the literature review. These help us to fom our 
design goals laid out in the next section. The following 
sections elaborate the features of LAMP as implemented and 
its grammar. A detailed description of the capability of 
LAMP in its job of translation is included in Section 4,3. 

Many real life optimization problems can be modelled as 
linear programming problems. In these situations a modeller 
describes the LP in a symbolic and readable form using familiar 
algebraic notation for variables, constraints and objective. 
However, for further processing, the computer algorithm 
requires the model in explicit and computer readable fom. 

These two forms of linear program viz. the modeller’s fom and 
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the algorithmic fora, are not much alike and both of these 
forms are essentially required for optimization, as no single 
means of expression could serve as both the forms. Thus any 
real life application of linear optimization requires trans- 
lation from one form to the other form. Translation from the 
modeller’s form to algorithmic form is thus an unavoidable 
task in mathematical programming based models. This process 
of translation has been found to be quite expensive, time 
consuming and difficult on the part of the modeller who plans 

C6€- 

to model real J.ife optimization problems^ Traditionally this 
Job of translation is accomplished by a matrix generator 
software . 

In the traditional approach to translation, the modeller 
first converts a symbolic modeller’s fora to a special com.puter 
program. The execution of that computer program generates a 
linear program in the desired algorithmic form. The inter- 
mediate computer program employs specialized programming 
language and is usually referred to as matrix-generator program. 
Matrix generators offer numerous advantages compared to the 
manual translation of modeller’s form to algorithmic form. The 
principal advantages are [6S]; 

. They provide an elegant way of organizing and 
storing problem data which is reasonably large 
in most real life modelling situations 

. The 3 ^ enforce a uniform scheme for naming rows 
and columns 
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. They enable the user to modify model structure or 
model data with much less work. 

However, the common design of matrix generators had 
serious limitations* 

. Matrix generators run in hatch mode and require their 
own file structure or environment 

. The algebraic form of model still has to be trans- 
lated by hand to an MG program. Writing this program 
is difficult as it requires strong skill of special 
programming language 

. Large MG programs are hard to follow 

. Devising unique names for rows and columns is often 
awkward 

. They are not readily adapted to nonlinear programming 
situations, because most general nonlinear problems 
could not be expressed in terms of matrix columns. 

In the modern approach to transl^'ition the idea is to 
have maximum possible work of translation done by machine 
itself i.e., the modeller should deal with the computer 
directly in modeller’s form using a special kind of one such 
form. This special modeller’s form should be easy to write 
and understand for the user and easy to read and translate 
for the computer. Centred to such an approach is a machine 
readable modelling Ifmguagc that expx'esses the mathematical 
program in much the same way as the modello^r does i.e., by 
employing a vctriant of algebraic form that is designed to be 
read by a computer system. This m.achine readable algebraic 
form is referred to as a modelling language (ML) . It differs 
from common algebraic form mainly in employing 
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standardized notation and terminology. A modelling language 
may be treated as a modern replacement for traditional matrix- 
generator language. Essentially both are the ways of describ- 
ing a linear program to a computer system. A modelling 
language makes no reference to the LP matrix. It serves only 
to represent an algebraic form of the model [66] whereas a 
matrix-generator language describes a linear program by speci- 
fying all of its non-zero matrix coefficients. The modelling 
language is not a programming language, where as a matrix- 
generator language is. 

Consequently 5 , a modelling language can make the LP 
modelle’r’s life easier in a number of ways^ 

. It is easier to learn than special purpose 
matrix-generator language. 

. The algebraic description of modelling language 
can serve as a documentation of the model. 

. It can identify constraints and variables by 
familiar method of subscripting. 

. It can be easily adapted to nonlinear models. 

The concept of modelling languages has been successfully 
used for other kinds of model] ing v/ell. However, most of 
the applications of modelling language to linear programming 
have been of smaller scale or have used the concept of a 
modelling language to a limited extent. Further, it is 
generally accepted that modelling languages lead to a more 
reliable modelling schema often at a lower overall cost [6B]. 
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The modern approach of modelling languages has specific 
inherent advantages over traditional approach of matrix 
generators. The general drawbacks of matrix generators were 
mentioned in Chapter II. The advantages of modelling languages 
over matrix generators are outlined bolow (in the same order). 

Verifiability * 

The major consideration here , is to determine 
whether the modeller’s form correctly represents the reality; 
one should also check v/hether the algorithmic form is a correct 
translation of the modeller’s form. Use of modelling language 
necessitates proper conception of reality and its representa- 
tion which can be treated as debugging of ML representation. 
This is relatively much easier as verification task reduces 
to an item-by-item comparison between modeller’s conception 
and the possible realization from the modelling language. 

Thus ML verification is less costly both in human and computer 
time and promotes ease and reliability. 

Modifiability ^ 

This refers to determining a new modeller’s form 
expressed in the modelling language, when there are changes 
in reality. The modelling language representation can be 
modified directly with ease. Thus linear program modification 
in modelling language systfjm is less costly. The modelling 
language offers similar advantages with respect to 
modifiability as in the case of verifiability. 
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Dpcumentability s 

This refers to maintaining all relevant information 
pertaining to different foims and their relationships. Modell- 
ing language system avoids extra documentation. Thus the 
documentation task is made simple and easy. 

Independence 5 

This refers to conceptual dependencies on particular 
algorithmic form. Modelling languages depend less on choice 
of algorithmic form and therefore modeller need not be incon- 
venienced by the need to know about particular algorithmic 
form. 

Simplicity s 

This refers to the need of any intermediate form between 
modeller's form and algorithmic form. In contrast to matrix 
generators, modelling languages require no intermediate form. 
Modelling languages interact with people through few simple 
forms thereby enabling easier modelling for linear prog ramming £6^. 

Further, a modelling language specifies its detta symbo- 
lically in some natural and familiar pattern similar to 
modeller’s form. It is not concerned with explicit data and 
enforces distinction between symbolic and explicit data which 
leads to more flexible and convenient management of the data 
for linear programming. The symbolic representation of data 
promotes reliability by serving as a check on the validity of 


•I 0 is Su.'S 
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the explicit data. In the modelling language system, the 
ML translator can detect explicit data that are not in con- 
formance with symbolic data and hence any data error has good 
chance of being caught and corrected before an erroneous 
algorithmio form is generated. Modelling languages being 
independent of algorithmic form may employ more flexible 
notation based on subscripted or indexed identifiers for 
naming LP components. Use of indexed identifiers makes 
linear program modelling easier. Modelling languages promote 
row-wise organization based on v.iriable- and- constraint (row- 
wise) form leading to greater flexibility and power^ The 
evident weakness of modelling languages is that they are hard 
to implement. However, the benefits out-lined above represent 
the significant advantages of using a modelling language. In 
the light of the above advantages several protot3^e modelling 
languages have been under development, for example-, ALPS [ 170 ]^ 
GAMS [105], LMC [122], LPMODEL [ IO3] , MAGIC [52j, MGG [147], 
and UIMP [l67] in the recent years. LAMP has boon developed 
at IIT Kanpur, both as a vehicle for teaching/research and to 
try out our ideas on the synthesis of flexible data and model 
access, which in our view constitute the central theme of the 
decision support system. 
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4.2 DESIGN GOALS 

A modelliiig language must fulfil the conflicting require- 
ments imposed by the demands of the modeller on the one hand 
and the requirements imposed by the computers on the other. 

From the modeller’s view the modelling language should be 
easy to use and understand. It should have terminology that 
is convenient to the modeller. The expressions of a modelling 
language need to be powerful and yet flexible. From the view 
point of the computer system, the modelling language should 
be capable of being processed and translated at reasonable 
cost and time. The syntax and semantics of the modelling 
language must be unambiguous and simple. The notation and 
symbols must be representable with the standard "ASCII'' 
character set. Representative keywords would replace special 
symbols that have natural meaning to the environment such as 
"sigma" for summation. In order to make the language useful 
to several model builders, it must have a grammar which is 
simple and yet powerful. As the grammar specifies what 
constructs are acceptable within the language, a simple 
grammar will permit any potential user to learn the language 
with minimal effort in a relatively short period of time. 
Additionally, the grammar should be free from exceptions and 
still be general enough to handle the diverse needs of model 
builders or potential users. 
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Any practical modelling language is a compromise between 
the conflicting requirements imposed by modeller and computer 
system. This compromise can be carried out in many possible 
ways leading to various kinds of modelling languages, with 
greater priority for some specific features. The requirement 
of user convenience can be met ideally by using an existing 
modeller’s form as a modelling language. Through several 
years of use and continuous refinement, common modeller’s 
form have been made convenient and understandable and their 
notation offers the desired power and flexibility. However, 
these existing modeller’s forms are intended entirely for 
human communication and are neither readable nor translatable 
by foreseeable computer systems,. Like any natural language, 
they are also ambiguous, complex and their meanings are context 
dependent. Moreover, some important notations, such as, summa- 
tion sign and subscripts are even now incompatible with ordi- 
nary computer hardware. 

Nevertheless, an existing modeller’s form is a reasonable 
point to start with for the design of an attractive and work- 
able modelling language,, Actually, such a form need only to 
be modified, so that it can be read and processed by the 
computer. Essentially, the variety and complexity of the 
existing modeller’s form must be reduced, so that every 
e^qDression has an unambiguous syntax and meaning^^he choice 
of an underlying structure of the modeller’ s form is an 
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important decision in. the design of a modelling language. 

Systems like f^POS [46] and LINDO [144], use "f ree-form *' input, 
where the user specifies each of the constraint as if he were 
writing on a piece of paper. Such a structure while undoubtedly 
attractive, is very inefficient for large problems where 
recognizable structure occurs, which can be generated automa- 
tically. Traditionally in analytical work, one views linear 
programming as a set of constraints generally referred to as 
''row-wise form" Because of its flexibility, power and natu- 
rality, row-wise modeller’s form is used as the underlying 
structure of representation in LAMP. 

With these observations we can finally state our goals 
as^ 

(i) The modelling language must be declarative i.e., the 
user should only define and describe the problem and no 
algorithm need be presented by him for formulation as that 
will be done by ML system in a standard way for all the models, 

(ii) The modelling language must be symbolic i.e., most of the 
problem elements - variables, constraints and objective, be 
representable using mnemonic symbols. 

(iii) The modelling language should be general , i.e., it 
shoifLd be capable of defining most of the linear programming 
models having a linear objective function to be maximized or 
minimized along with a set of linear constraints. Moreover, 
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it should be extendable to integer and nonlinear programming 
situations as well. 

(iv) The modelling language should be understandable i.e., 
the s^mtax and semantic features should represent the language 
in such a way that the user will be able to comprehend it 
easily. 

(v) The modelling language should be natural i.e., model 
can be expressed in terms natural to the domadn of the problem. 

(vi) The modelling language system must be readable on any 
interactive terminal with a limited standard key board 
character set. 

(vii) The modelling language system must be sufficiently user 

friendly . A modem modelling language system should facilitate 
interactive session as well as batch operation. During the 
interactive session a modeller should be able to operate the 
system by typing commands at computer terminal j and the system 
should be designed to send relevant messages and results back 
to the terminal as it runs. A user friendly system should be 
designed to have message display pertaining to specific 
information from user, error messages flashed resulting from 
improper-usex input and should have necessary recovery 

mechmism. In batch operation the user or modeller can submit 
the whole set of commands and model information using exter- 
nal files and get result when the entire job is completed. 
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Interactive session affords closer control of a system and 
gives a better feel for what is going on. A modeller can 
watch the model construction by having it report periodically 
or at designed stages on its progress. Interactive session 
is quite useful for model construction phase as the mistakes 
can be corrected as they turn up. Interactive systems conse- 
quently encourage experimentation which is essential to 
successful modelling. Ease of experimentation also makes 
an interactive system easier to leam. The modelling language 
system should concentrate on the construction and development 
of the model rather than on its solution. The modelling 
language system should have sufficient syntactic and semantic 
error analysis capabilities in a way to help the modeller find 
mis specification in his model. 

(viii) The modelling language system should b-- based on 
modifLarity concept i.e,, dividing the larger task into smaller 
sub tasks that can be treated separately. Tho modeller should 
not be restricted by any order in which the various components 
of a model need to be v/ritten, apart from the contextual 
naturalness considerations. 

(ix) The modelling language shoifLd have abstraction capability 
i.e., the systtm shoiild be capable of expressing nature of the 
problem independent of particular details such as numerical 
constant. 
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(x) The modelling language system should have provision 
for models to be nested^ so that the output of one model may 
be used as input to other model, if required. 

(xi) Any modification to existing modelling language system 
should be simple to implement. 

(xii) The modelling language system should be able to interface 
with existing databases in such a way that not more than a 
minimum of knowledge is required from the modeller. 

(xiii) The modelling language system should be portable , so 
that the model representation is independent of computing 
equipment. 

(xiv) The modelling language system must meet atleast the 
following features with reference to linear programs, 

(a) Symbolic identification of linear program components 
i.e., constraints, variables, R.H.S. and objective. 

The abstract model form of constraint or objective is to 
be modelled in row- wise manner. 

(b) Grouping of variables and constraints i.e., the system 
has to permit variable grouping and a particular type 
of constraint grouping. 

(c) Indexing e3q)ression i.e., specifying how a group of 
expression is indexed. 
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(d) Ability to parametrically specify constraints, variables 
i.e., the system has to build abstract constraints with 
parameters such as ''ALPHA*' , indexed coefficient and 
variable. 

(e) Special features: e.g. , system should have provision for 
simple and generalized upper bounds, time lag/lead fea- 
tures. Most of the linear programs are likely to have 
simple upper bounds and generalized upper bounds. Also, 
some linear programming situation may necessitate the 
incorporation of time lag/lead aspect to model a 

wide variety of real life applications. 

(f) Interface with standard problem solving software for 
linear program and a standard database management 
softwares The model generated by the modelling language 
system needs to be solved for optimization using standard 
problem solving software. Further the result so obtained 
as well as input data need to be utilized for generation 
of related desired information and ansv/ering query raised 
by the user. Effective query system necessitates the 
use of a standard database management system software. 

(g) Automatic .generation of coefficients in special cases 
such as generalized and simple upper bounds; In order to 
minimize the coefficient values supplied by the user 
during interactive session or through external file in 
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batch operation, the system should generate appropriate 
coefficient values at the run time for some special 
cases of generalized or simple upper bounds. 

(h) Blending constraints? i.e. , the system should have 
provision for blending type constraints commonly 
required for modelling in process industry environment 
where the output of one process becomes the input for 
the next process. 

The above features have been adopted as the design goals 
in our imiplementation. They were arrived at after extensive 
study of the existing systems under development else^vhere. 

The major emphasis, however, is on proving the ideas and not 
on the development of a softw'arc product, which calls for much 
larger investment of a different skill. 

4 . 3 IMPLEMENTATION s 

^•3.1 Introduction s 

The modelling language system, LAMP, has been implemented 
on DEC-10 system at IIT Kanpur. Most of the code is written 
in PASCAL [98], The exercise has been primarily to prove 
the ideas, rather than developing a full fledged software 
product. Hence the diagnostic capabilities of the model are- 
limited. However during interactive session or in batch 
operation error and other relevant messages are flashed back 
for modeller’s or user’s help. The system has, however been 
well tested. 
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The LAMP system uses UNDO [145] and GINO [114] as problem 
solving software for linear and nonlinear programs respectively. 
The data management software is the package UNIFY [168] that 
runs on the UNIX [169] based machine UPTRON S -325 available at 
IIT Kanpur which is networked to DEC-10 machine. 

The actual model building is in two stages, model struc- 
ture definition and model data definition. In the first stage, 
modeller defines the terminology and then the abstract struc- 
ture of the model using a simple syntax detailed in Section 
4 . 5 . 2 . In the model data definition phase the data are 
generated by executing the model structure with the data on 
files or provided by modeller during interactive session to 
produce the actual data for interfacing to a problem solving 
software. The format of the generated data are an industry 
standard MPS file [92] and row-wise equation form for input 
as well as a relational format discussed in the next chapter 
for both input and solution values, which we believe would 
be the future generation standard. The salient features of 
implementation are described below. 

4.3.2 The Grammar s 

The syntax of LAMP has been kept close to the way the 
mathematical programs are typically written by most modellers. 
The summation symbol has been replaced by 'SUM” to enable one 
to use LAMP even v/ith ordinary terminals. The other parts of 
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the modelling language use natural symbols. Many of the 
ideas are based on LR40DEL [l03]« 

The basic building block is an atom , a group of atoms 
constitute a molecule . Molecules are typically used as index 
variables. A t 3 ;pical example would be the moleciole "MONTH" 
consisting of atoms "MAY", "JUNE" and "JULY". The variables, 
constraints and objective function are built out of identi- 
fiers v/hich may be scalar or arrays, indexed over the mole- 
cules. To provide maximum flexibility, LAMP allows different 
molecules to have common atoms and provides automatic genera- 
tion of cartesian products for summation. LAMP also provides 
for variable to appear on right hand side when it is natural 
to modelling. Multi-level indexing of identifiers, multiple 
terms and paramttric terms are also permitted by LAI'IP. The 
values corresponding to coefficient identifiers aro stored 
in files (possibly obtained from corporate data base of the 
organization through the use of some databoi-se management 
software) or provided by user during interactive session and 
the matrix generated at the time of execution of LAMP. LAMP 
provides for automatic generation of coefficients in the case 

of specially structured constraints such as simple i;ipper 

/ 

bounds or generalized upper bounds. 

A compact and complete way to describe the 
modelling language used in LAMP is accomplished by providing 
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its gra mm ar^ The grammar is a set of rules that determines 
which are the valid constructs in the language. It describes 
the syntax. Moreover, one still needs to explain the meaning 
of the constructs, usually referred to as semantics, for 
user^'s familiarity with the grammar, the EBNF (Esctended 
Backus Naur Fonn) syntax for terminology, objective and cons- 
traint — equations and assignments has been provided. Hope- 
fully it is to be used as the key to a quick ■understanding 
of what constructs are syntactically correct. The detailed 
syntax of the language in Standard EBNF form [98 ] is given 
in Figure 1 . 

The modelling language grammar is written using standard 
notation (pattern) of EBNF and contains the following symbols 
knom as meta- symbols. 


Meta- Symbol English Equivalent 

= is defined to be 


Use 

Separates a phrase name from 
its definition 


alternatively (or) Separates alternative 

definition of a phrase 


period or full 
stop 


end of production 


Additionally, the meta-symbol [... ] refers to the optional 
(zero or one) occurrence of enclosed construct and i..»} 
refers to zero or more occurrences of enclosed construct. 


The meta- symbol (XlY) refers to a groupings either X or Y. 
The meta-symbol "XYZ" refers to the terminal symbol XYZ. 



» » NOTE 


Lines starting with are 'Continent' lines 


% 


Heta^ymbol Heanans 


1X3 

<X> 

(> ! Y ) 
■XY 2 - 


is defined to be 
alternatively 
end of aroductiorj 
0 or 1 insterice of X 
0 or n»ore instances of X 
a srouFins: either X or Y 
the teriT.irial symbol XYZ 


F rob len- 


Terrj.iriolosb 


■Probletr. * 

Termirjol ogy 
Object 1 ve 

Const rsi fit _seauer»ce ♦ 

Mol ecule-seouence 
Identif 1 er -.seouence • 


Holecul e>.seeuence 


holecule_-def ini t lori ‘eolri ■ <holecul e_defi nation 


hole C'j} e_def 1 rut ion 
holecu! e-_n3n»e 
AtDiT!_nante 
K'an r 
L alter 

Alpha nume- r i c 
Disit 


hclecule-nsme • = “ Aton -nameC * f • Aton._n 3 me> * 
Name * 

Nsn*e ♦ 

Letter-CAlphariun er ic> ♦ 

< 'a* ! -b* : , . I -z* > ♦ 

Let tei I D a Si t * 
c • 0 * ; * 1 • ] . * ; • 9 • > * 


Ider.taf a & r _s eoue. ic 


loanlafaer'S* • eoln*-CIderat af ler ■ $ ■ * eoln " > . 


Identifier 


Nan'e-C*’ ♦ * Mol ecule» name!-. 


Gi -•£ 1 1 i 
0 p f ' a t o T 
LHS 

TerfM.sF 3 
Far n._ tern 
7 e - fii 

Pa T en>eter 
Summe t aon^id 
Coef f 1 C lent^io 
Uara abJ e_id 


O-eratcT LHc'ealn'* 
i *hJN" ! "nAX* ) * 

Terror •t'lern -5^13 , 

<Te rni t F arn._ternj) ♦ 

Faran<cter Tern. * 

" C • Suniit.at aon_id“ I "Coef f a c a ent-i d “ * Varisble^id 

<•?" } { *>“), 

Nsn<e ♦ 

Ho 3 ecule-name-C • J •holecule_n 3 n«e> ♦ 

Ident a f a er ♦ 

( Mol ecul e^name Ideritif aer) ♦ 


Const T aint_se«vjence = 

Generol^seeuence = 

Gene r a 1 ons t r a a nt - 

RHS 

Spj-seGoence 
Spl-constYaarh = 

Bouridc^coris _seG - 

Bou.nds -const rairit = 

Sample- sun, -cor £_se& - 

S 3 la_£Uni_corirt raint - 




Gene r a 3 _s eG jence-CSpl_seGuence> * 

General-co.nstroint •eoln*-CGerieral -constraint 
•eolri*>* 

"SUh'LHS<* =^“ J *. =• 1 • = • )RHS* 

Idarit 3 f aer* 

Sel-const raint •eoln’tSpl-.corist raint * eoln •>• 
-CEo.jrjds_cons_seGl -Csimp le-Sura_cons_seG> * 

Bounds_cor is t r a i nt * eol n " -CBounds -corjs t r Eint*colri*> , 
(Mclecula -name n dent if ler ) • C ■ \ * -•{•=^*)RHS4 

Sin.P 1 e-sunj . const rai nt " eolfi * tSa np 1 g_s ur - constrairil 
•ecin’-l . 

*cur'i" • C •Sum>i,<.tiDr,-.id‘ : *Vc T aatae-id"? • • 3 " 

( - = • ; - ; • = • )RKS* 


Fig 


EEI^F Grammar for ILrJ'lP 
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In the Extended Backus Naur Form (EBNF) the rneta-symbol <...> 
enclosing non“terminal symbols have been dropped and any 
s^mibol which does not appear on the left side of a production 
is a terminal symbol. The symbol "eoln” is used to indicate 
the end-0 f “line feature. 

Every effort has been taken to keep the representation 
as natural as possible i.e., the model can be described in 
terms natural to the domain of the problem. The language is 
based on limited character s-'t usually available on standard 
terminals e.g., (no Greek letters). It permits no subscripts 
and superscripts. It allows algebraic operators ” + " for addi- 
tion and ")s-''for multiplication. Using above described meta- 
symbols as primitives and constructing multi- character names 
for variables, identifiers and parameters, the modelling 
language builds the model as algebraic equation or expression 
which represents the real life problem under consideration. 

For example, a typical constr^’int set could be 

SUM[ MONTHI FERTREQ. CROP . ]yiONTH*MONTH 2] < = TFERTREa. CROP 

indicating that the fertilizer required (FERTREQ) summed over 
all the months must be limited to the total fertilizer 
(TFERTREQ) required for every crop. The coefficients indicat- 
ing the fertilizer requirement come from the indexed identi- 
fier (FERTREQ. CROP. MONTH) . The molecule name to the left of 
the symbol 'h ” i.e,, "MONTH," represents the summation set. 
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The decision variables are indicated by ”MONTH?", The actual 
decision variable corresponding to this constraint v/ill be 
all the atoms associated with the molecule name "MONTH*'. It 
may be noted that the model structure is independent of data 
i.e., the structure of the constraint set would be independent 
of the number of months considered for planning. 

4.3.3 Salient Feature s s 

The main features of the LAJMP system are as follows^ 

(i) Indexed Constraints !. 

LAMP allows a simple definition of constraints indexed 
by one or more molecules, permitting multi-level indexing 
(upto three levels are permitted in the current implementa- 
tion) . 

Example i 

SU])l[CROPlLABORKEQ.CROP.MONTH*CRDP ?] <= LABORAVL. MONTH 

This abstract form of the constraint v/ill finally 
generate as many no. of constraint -inequalities as the number 
of atoms for molecule 'MONTH'*, labelling each one of them by 
particular atom names corresponding to molecule ''MONTH'.’ 

(ii) Sum of Terms » 

LAMP allows a constraint or a set of constraints to be 
composed of more than one symbolic term. 
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Example* 

SUM[CROP S WATERREQ. CROP . MONTH*CROP ?] + 

[ LIV STOCK! VfATERREQ. LIVSTOCK. MONTH* LIVSTOCK ?] 

<= TOTWATER. MONTH 

This abstract form of the constraint will finally expand 
both the terms in row-wise manner, firstly "CROP" atoms as 
variables and later "LIVSTOCK" atoms as variables indicat- 
ing that the water required summed over all crop atoms and 
water required summed over all livstock atoms must be limited 
to the total water available (TOTVATER. MONTH) for every month. 
The number of constraints generated will be same as the num- 
ber of atoms for molecule "MONTH". 

(iii) Sum of Terms with Constant Multipliers ? 

For parametric analysis one would like to have provision 
for a constant multiplier to be included in the model. LAMP 
is capable of handling such feature. 

Examples 

MAX[ CROP ! PRO FIT . CROP* CROP ?] + 

ALPHA[ LIVSTOCK! PROFIT. LIVSTOCK* LIVSTOCK ?] 

In this abstract form of the constraint "ALPHA" has 
been used as a parameter. The value for this will be provided 
by user at run-time. 
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(iv) Blending Constraint » 

In process industries blending type constraints are 
frequently used to represent process energy or resource 
balance. 

Examples 

SIM[PR0CESS1 i HEAT . PR0CESS1*PR0CESS1 ?] + 

ALPHA.[PR0CESS2 S HEAT . PR0CESS2^PR0CESS2 ?] 

= ZERO 

(v) Bounds s 

Most mathematical programs contain bounds. Special 
algorithms like bounded variable algorithms exploit this 
structure. LAMP permits for bounds as a special constraint 
and the modeller need not provide the coefficients i/^hich are 
automatically generated at run-time. 

Examples 

CROP’ <= CEILING. CROP 

This abstract form of the constraint will generate a 
set of simple upper bound constraints. The number of cons- 
traints generated will be same as the number of atoms for 
"CROP" molecule. 

(vi) Simple Summation s 

A good number of constraints in any mathematical program 
is in the form of a simple summation of a set of variables. 

In order to save the unnecessary entry of these coefficients 
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in the data file^ LAMP permits automatic generation oi such 
unit coefficients. 

Examples 

SUM[ CROPS CROP'?] <= TOTLAND 

This abstract form of the constraint will generate a 
single constraint with all coefficients as mity for each 
atom of the "CROP" molecule and the summation must be 
limited to land available for " CROP " i.e., (TOTLAND). 

(vii) Special Feature ss 

Special features include the generation of combina- 
torial constraints. The cartesian product of indices can 
be indicated in the model structure rather than explicitly 
defining a molecule listing of the elements of the cartesian 
product . 

Example s 

MIN[ ROWS COLIMW s COST. ROW. COLUMN *ROW. COLUI® ?] 

This abstract form of the objective function will 
generate the cartesian product corresponding to ROW, COLUMN 
and using double summation concept write the objective 
function. 
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(viii) Restricted Summation ^ 

Restricted summo-tion can be handled by defining another 
molecule consisting of restricted atoms. 

Example o 

MIX = APPLE, liANGO 

This indicates that molecule "MIX" is defined to have 
atoms as "APPLE*' and "tlAEGO". Then the abstract fora of the 
constraint 

SlEl[MIX;'MIX ?J <= CEILMIX 

will generate a single constraint of simple summation type 
i.e., similar to generalized upper bound constraint compris- 
ing of only two variables viz. "APPLE" and "MAI'jGO ", 

( ix) Nonlinear Terms i 

Nonlinear terms can be handled by interactively specify- 
ing the form of nonlinearity of objective function/constraints. 
The current implementation allows simple polynomials and stan- 
dard trigonometric functions only. The variables associated 
with nonlinearity is indicated by double question mark (??) 
instead of single question mark (?). 

Examples 

MAX[ CROP s, WATER. CROP* CROP ?'' ] 

This abstract form of the objective function will gene- 
rate the objective function expression after getting the 
nonlinear parameter information from the user at run-time. 
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(x) Variable Right Hand Side s 

Variable right hand side is allowed by LAI'4P 
which may sometimes be required for meaningful constraint 
modelling. Variable on the right hand side feature is 
indicated by brace (}) closing instead, of bracket (J j closing 
used in the abstract form of the constraint. 

Examples 

CROP S WATER, CROP^ CROP *?} < = TOTWATSR 

This abstract form will generate constraint expression 
having variable on the right hand side after getting the right 
hand side variable name information from the user at run"time. 

4.4 ILLUSTRATIVE EXA['4PLE 

4.4.1 Sample Proble ms 

To illustrate the capability of the LAIdP system, we will 
use the following agricultural planning example adopted from 
[ 103 ] and modified slightly to represent LAI4P capabilities. 

A farm manager is planning for the next season consisting 
of tho periods May, June and July. The various crops for the 
season under consideration being cotton and onion (cul tivation 
crops grown in a field) and apples and oranges (grown in an 
orchard). The land availabilities for the field and the 
orchard are 1850 and 600 units out of tne total 2/00 units, 
the brilancc being used for grazing. The labour availability 
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is limited to 5850 units. The total availability of water 
is limited to 205000, 265000 and 275000 units in the months of 
May, June and July respectively, out of which 200000, 260000 
and 270000 units only can be used for crops. The correspond- 
ing availability figures for fertilizer are 4000, 5000 and 
6000 units. The farm is maintaining livestock i.e., cattle 
and sheep also. The per unit profit contributions per unit 
area of cultivation and similar figures for the livestock 
type are known. There are bounds on the production level of 
the crops and livestock. In addition, a minimum quantity of 
production must be ensured. The per unit requirement of 
water, labour and fertilizer are given. The entire data is 
summarized in Table 1 to Table 7. The farm manager is 
interested in an optimal strategy thet maximizes his revenue. 


Table 1-' Land Availability 


Jield 

Orchard 

Total 

1850 

600 

2700 


Table 2As Average Unit Labour 
iiequirement 

Tabic 2B; Labour Availability 

Cotton Onion Apple Orange 

Total 

2.9 2.7 1.0 1.2 

5850 



Table Unit Water Requirement. 




Cotton Onion Appl 

e Orange 

Cattle Sheep 

May 


65 - - 


0.1 0.4 

June 


80 60 50 

75 

0.2 0,5 

July 

90 - 64 

85 

0.3 0.6 

Table 

3B2 

Water Available 
for Crops 

Table 3C2 

Total Water 
Available 



Quantity 


Quantity 


May 

200000 

Mav 

205000 


June 

260000 

June 

265000 


July 

270000 

July 

275000 

Table 

A* Ac 

Unit Fertilizer 
Requirements. 

Table 4B^ Fertilizer 

Availability 


Cotton Onion "Apple Orange Quantity 


May 

1 

4 

7 10 

May 

4000 

June 

2 

5 

8 11 

June 

5000 

July 

3 

5 

9 12 

July 

6000 

Table 5» 

Unit Profit ConLribution. 


Cotton 

Onion 

Apple 

Orange Cattle 

Sheep 


6453 

6110 

4814 

8812 500 

600 
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Table 

6As Bounds for Crops 

Table 6Ba Bounds for 
Livestock 

Cotton 

Onion Apple Orange 

Cattle Sheep 

2000 

250 500 800 

400 300 

Table 7As Yield Data 

Table 7Bs Minlm.um Production 

Cotton 

Onion Apple Orange 

Quantity 

12 

13 14 15 

15000 

4.4.2 

LAMP Formulation of the 

Sample Problem® 


4'he sample problem discussed in sub section 4.4,1 is 
written in LAMP using grammar syntax specified in Figur'e 1. 
The terminology phase appears in Figure 2 and the abstract 
model stD^ucture phase comprising of objective and constraints 
appear in Figure 3= 

The various phases of model formulation for the above 
mentioned agricultural planning sample problem is further 
explained in detail. Based on specific requiremenb^s) Oj. 
the sample problem, Fig. 1 representing terminology phase 
depicts the description of various molecules and identifiers. 
The molecules defined are "MONTH" with "MAY", JUNE and 
"JULY" as its atoms; "CROP" with '"COTTON", "ONION ", "APPLLl " 
and "ORATJGE" as its atoms; "FIELD" with "COTTON and ONION 
as its atoms; "ORCHARD ” with "APPLE" and "ORANGE" as its 





- »»jL 1.11 « are 

% TERMINOLOGY PHASE 

% MOLECULE 

MONTH=MAY . JUNE i JULY 
CROP==COTTON 7 ON I ON f APPLE f ORANGE 
FIELI«==COTTONfONION 
ORCHARD^APPLE r ORANGE 
LIMST0CK=CAT7LE 7 SHEEF* 
RES0URCE=LANHrLAB0R7UATER7FERTL2ER 

% IDENTIFIER 

t LAND AVAILABILITY : 

TOTALAMLi 
FIELDAVLi 
ORCHAUL$ 
t LABOR : 

LABORREO*CROP$ 

LABORAVL$ 
t UATER : 

WATERREO . CROP . MONTHS 


Ccjiftment ^ lines* 

; s. ss SE s BE 6E sr as sc r: = js St as as 


< Table~2 > 

( T3ble-2A > 

< T3ble-2B ) 
( Toble-Z ) 

< Tsble-ZA > 


WATEPF LQ^LIVSTOCF ^MONTHS 
TGTWATEFw MONTHS 
WATERAUL*HONTHS 
t FERTL2ER : 

F£RTREQ*CROP. MONTHS 
FERTAUL*MONTH$ 

* UNIT PROFIT : 

PROFIT* CROPS 
PROFIT *LIVSTOCKS 
if BOUNDS : 

CEIL*CROP$ 
CEIL*LIUSTOCK$ 
t YIELD : 

YIELD* CROPS 
MINFRODi 


1 T3ble-3A ) 

( T3ble-3B ) 
C T3ble-3C ) 

< Table-A ) 

< Table-AA > 
( Tsble-AB > 
( T3ble-5 ) 

< Table-6 ) 

( T3ble-6A ) 
( T3ble-6B > 

< Tsble-7 ) 

( Table-7A ) 

< T3ble-7B ) 


Fif* 2: Agricultural Problem Terminology Phase 



t PROBLEH STRUCTURE 

* OBJECTIVE 

HAX CCROF:PROFIT,CROP»CROP'i^ 3 f ALFHAI:LIVST0CK;FR0FIT4LIVST0CK*LIVST0CK'?^3 

t CONSTRAINTS 

t Uaterevai lability (Total ) 

SUHECROPtUATERREQ.CROF •MONTHikCROP'!’] + CLIVSTOCK;UATERREQ.LiySTOCK.MONTH*.LIVSTOCK 
I'D s=TOTUATER.HONTH 

Labouravailability 

sumi:crop:laborreq*crop*crop'?3 laboravl 

* Landavai Isbi 1 ity 

SUHrCROP:CROP'?3 • = TOTALAVL 
3^ Fieldlandavailability 

SlthCFIELD:FIELD'^^3 FIELBAVL 

* Orchardlandav'ailebil 3 tb 
SU*lC0FCHAP’rt:0RCHARD'?3 ~ ORCHAVl 

% Wateravalobilaty for ctops 

SUHLCR0P:UA1ERRED»CR0F ♦H0N1H)»*CF0F7 3 = UATERAVL.HONTH 

f Hinimunj yields 

SUHLCROP:YIElIuCROP3t^CROP'?3 ,= hlNPROB 
t Fertilizer consumption 

SUMCCR0F:FERTREQ.CR0F.M0NTH*CR0F-?D = FERTPVL. MONTH 

$ Ceil ins on cro®s 

Cf;^OP'? CEIL 4 CROP 

* Ceilins on livestock 

LIVSTOCK'^^ CEIL^LIVSTOCK 


if. 


3: Agricultural Problem Model Structure 


atoms "LIVSTOCK’' with "CATTLE" and "SHEEP" as its atoms 
"RESOURCE" with "LAND", "LABOR", "WATER" and "FERTL2ER" as 
its atoms. Then the identifiers defined are " TOTAL AVL ", 
"FIELDAVL" and "ORCHAVL" to represent land availahility 
features based on data from Table 1; "LABORREQ.CROP" and 
"LABORAVL" to represent labour features based on data from 
Table 2A and Table 2B; "WATERREQ.CROP.MONTH", "WATERREQ. 
LIVSTOCK. MONTH", " TO TWATER. MONTH" and "WATERAVL. MONTH" to 
represent features related with water resource based on 
data from Table 3A, Table 3B and Table 3C; "FERTREQ. CROP .MONTH 
and "FERTAVL, MONTH" to represent fertilizer features based 
on data from Table 4A and Table 4B, "PROFIT. CROP" and 
"PROFIT. LIVSTOCK" to represent unit profit features based 
on Table 5,* "CEIL. CROP" and "CEIL. LIVSTOCK " to represent 
bounds information based on data from Table 6A and Table 6B; 
"YIELD. CROP" and "MINPROD" to represent yield features based 
on data from Table 7A and Table 7B. 

Next in the abstract model structure phase first the 
objective function equation is developed and then the whole 
bunch of constraints representing the real world problem as 
a linear program is developed. However, the constraints 
need not be in any particular order i.e., the modeller can 
develop the constraints in abstract form in any sequence. In 
order to fulfil the farm manager's strategy of maximizing 
his revenue in the example problem, the LAMP representation 
of objective function will be as, 
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MAX[CROPsPROFIT.CROP*CROP’] + 

ALPHAL LIVSTOCKi PROFIT. LIVSTOCK*LIVSTOCK?] 

The above abstract form representation of the ot'oective 
function will generate a single expression considering profit 
contribution coming from crops and livestocks. The actual 
data values for coefficients will be coming from the associated 
identifier data values stored in the system during r'an-time. 

The value of the parameter, "ALPHA” will be supplied by user 
as 1.0 or any desired value at run-time. Based on above 
information, LAMP system generates the exact escpression for 
objc ctive function. 

Now considering the total water availability as resource, 
tilt! LAMP representation of associated restriction in abstract 
form will be as 

SUM[ crop S VaTLRREQ. CROP , M0NTH*CR0P ?] ^ 

+ L LIV STOCKS WaTERREQ. LIVST0CK.M0NTH*LIVST0CK ?] 

<= TOT rfATER. MONTH 

The above abstract form of the constraint will generate 
three inequalities, one corresponding to each month (i.c., ’’MAY’', 
"JUNE”, "JULY"). The actual coefficient values will be coming 
from the associated identifier data values stored in the 
system during run-time. Similarly, considering the labour 
availability as resource for crops, the LAI'^P representation 
of associated restriction will be as 

SUM[CR0P5LAB0RREQ.CR0P=<-CR0P?] <= LABORAVL 
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The above abstract form representation of constraint 
v/ill generate an inequality with "CROP" atoms (e.g., "COTTON", 
"ONION", "APPLE", "ORAIC-E") as variables. The actual coeffi- 
cient values will be coming from the associated identifier 
data values stored in the system during run-time. 

Now considering the land availability as resource 
i.e., total land, field land and orchard land as separate 
resource, the LAMP representations of the associated restric- 
tion will be as 

SUM[ CROP; CROP?] <= TOTALAVL 

SUMl FIELD; FIELD ?] <= FIELDAVL 

SUM[ ORCHARD! ORCPiARD ?] <= ORCHAVL 

Each of the above abstract form will generate single 
inequality having unity (i.e., 1.0) as all coefficient values, 
generated by the system at run-time. 

Now considering the water availability as resource 
onl}^ for crops, the LAMP representation of associated restric- 
tion in abstract form will be as 

3IDI[ CROP; WATERREQ. CROP. MONTH*CROP 
<= WATERAVL. MONTH 

The above abstract form of the constraint will generate 
three inequalities, one corresponding to each month (i.e., "MAY", 
"JUNE", "JULY") with "CROP" atoms (i.e., "COTTON", ''ONION", 
"APPLE", "ORANGE") as variables. The actual coefficient values 
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v/ill be coming from the associated identifier data values 
stored in the system during run-time. 

Now considering the minimum yield requirements, the LAMP 
representation of associated restriction in abstract form 
will be as 

SUM[ CROPi YIELD. CR0P*CR0P ?] >= MINPROD 

The above abstract form of the constraint will generate 
an inequality with "CROP" atoms (i.e., "COTTON", "ONION", 
"APPLE", "ORANGE") as variables. The actual coefficient values 
will be coming from the identifier data values stored in the 
system during run-time. 

Now considering the fertilizer as resourcvi, the LAI'iP 
representation of associated restriction in abstract form will 
be as 

SU1V[[ CROP S, FERTREQ. CROP . M0NTH*CR0P ? ] 

<= FERTAVL. MONTH 

The above PAbstract form will generate three inequalities, 
ono corresponding to each month (i.e., "MAY", "JUNE", "JULY") 
with "CROP" atoms (i.e., "COTTON", "ONION", "APPLE", "ORAl^GE") 
as variables. The actual coefficient values v/ill be coming 
from tho associated identifier data values stored in the system 
during run-time. 

Finally, considering the various bounds e.g., ceiling 
on crop and coaling on livestock, the LAMP representation of 
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associated restrictions in abstract form will be as 

CROP? < = CEIL. CROP 

LIV STOCK? <= CEIL.LIVSTOCK 

Based on the terminology phase definition of molecule 
"CROP" having four atoms (i.e., ''COTTON", "ONION", "APPLE", 
"ORANGE") and molecule ’"LIVSTOCK" having two atoms (i.e., 
"CATTLE", "SIiEEP") the above abstract forms will generate 
four and two inequalities respectively. Similar to simple 
upper bound constraint, eaoh of the four inequalities will 
be having single variable as atom of "CROP" molec-ule and 
each of the other two inequalities will be having single 
variable as atom of "LIVSTOCK" molecule. 

Thus the entire formulation for the example problem 
as a linear program is completed. The LAI'IP system generates 
the formulation both in MPS format as well as in expanded 
inequa] ity form having entries only corresponding to nonzero 
coefficient values. These appear as Fig'ure 4 and Figure 5 
respectively. 

4.5 FURTHER EXAMPLES J 

To demonstrate the full capabilities of LAMP to model 
a variety of real life situations, three sample problems 
were selected from Ozon [l3l]- These are "Fcmdry Charging 
Problem." representing simple product mix decision; "Gasoline 
Blending Problem" that uses blending concept in a process 



» " NOTE ; Lir.es stertir.s with are 'Coi»i.,er,t ' lines. 

I Model 

NAME LINT GENERATEH MPS FILE( MAX) 

N 1 
L 2 
L 3 
L A 
L 5 
L 6 


L 7 
L 8 
L 9 


L 10 



L n 



G 12 



L 13 



L 3^ 



1 3 5 



L 



L 17 



L 18 



L Ih 



L 2'« 



L 23 



COLUHNS 



801 ION 

1 

<5453*00006 

ccaioN 

2 

65*00000 

COTTON 

Z*) 

80*00000 

COTTON 

A 

90*00000 

COTTON 

C 

2*90000 

COTTON 

6 

1*00000 

COTTON 

y 

1*00000 

COTTON 

9 

65*00000 

COTTOr^ 

10 

80*00000 

COTTON 

13 

90*00000 

COTTON 

12 

12*00000 

CG7T0N’ 

13 

1*00000 

COTTON 

lA 

2*00000 

C0170N 

ir 

3*00000 

COTTON 

16 

1*00000 

OfUD- 

I 

6110*00001 

Of IZ* 

3 

60.0DOCC 

Of* 1 Oh 

5 

2*6^999 

ONiO’ 

6 

1*00000 

ONI Of.' 

7 

1*00000 

ONION 

10 

60*00000 

ONI Of*' 

12 

12*99999 

ONION 

17 

4*00000 

ONION 

lA 

5*00000 

ONION 

15 

6 *0000 0 

ONICN 

17 

1*00000 

AF'FLE 

1 

4814*00001 

AF FVE 

3 

50*00000 

APFLE 

A 

63*99999 

APPLE 

5 

1,00000 

APPLE 

6 

1*00000 

Af PLE 

8 

1 *00000 

APPLE 

10 

50*00000 

APPLE 

11 

63*99999 

APPLE 

12 

14*00000 

APPLE 

13 

7*00000 

Af=*PLE 

14 

8*00000 

apple 

15 

9*00000 

APPLE 

18 

1*00000 


3f 


Fig. 4: Model Formulation in KFS Fcrmut xo 
Agricultural Problem (Contd.). 
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NOTE ; Lines stertins with ere 'Con.B,er,t' lines. 

MODEL FORMULATION IN MRS FORMAT for Asnculturel Model . 


ORANGE 

1 

8812*99996 

ORANGE 

3 

75*00000 

ORANGE 

A 

85*00000 

ORANGE 

5 

1*50000 

ORANGE 

6 

1*00000 

ORANGE 

8 

1*00000 

ORANGE 

10 

75.00000 

ORANGE 

11 

85.00000 

ORANGE 

12 

15.00000 

ORANGE 

13 

10.00000 

ORANGE 

14 

10.99999 

ORANGE 

15 

12.00000 

ORANGE 

19 

1 .00000 

CATTLE 

1 

600.00000 

CATTLE 

2 

0.10000 

CATTLE 

3 

0.20000 

CATTLE 

4 

0.30000 

CATTLE 

20 

1.00000 

SHEEF* 

1 

719.99999 

SHEEr 

•n, 

0.40000 

SHEEP 

3 

0.50000 

SHEE*^‘ 

4 

0.6000C 

SHEEF 

21 

1.00000 

RH5 

o 

205000.00119 

RHG 

3 

265000 *0005<? 

RHS 

4 

275000.00000 

RH£ 

5 

5B50.000C2 

RHH 

6 

2699.99998 

RHS 

7 

184^ . 

F H£ 

P 

600.000CO 

rh: 

c 

20000C .OOCOC 

FR'£ 

3C 

otj-,0 00'" ^c9C4;c 

F' H z 

11 

2<i^'S9S .99SSC 

RHS 


15000.00000 

RHC 

13 

4000.00000 

RHS 

14 

5000*00000 

RHS 

15 

6000.00000 

RHS 

16 

2000.00000 

RHS 

17 

250.00000 

FHS 

18 

500.0000C 

RHS 

19 

‘ 800*00000 

RHS 

20 

400.00000 

RHS 

21 

300.000DC 


ENDATA 

» 


Fi£. 


Kodel Formulation in MPS Format, 
for Agricultural Problem. 


. • (continued ) 


4 



note t Lines starting with are Xominerit' lines 
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t 

HAX 


! I 

6453#00006COTTrM 4 

600»OOOOOCATTLE 


6110.000010NI0N + 4814*00001APPLE 4 8812 • 99??60RAHSE 

4 719.99999SHEEP 


ST. 


4 


4 


65,OOOOOCOTTON 4 
SO.OOOOOCOTTON 4 
0*20000CATTLE 


265000 ♦ 00059 
*’90.00000COTTON 4 

0.60000SHEEP 
2*90000C0TT0N 4 


1850. 0000 
♦OOOOOCOTTON 4 


n 


C.IOOOOCATTLE 4 

60.000000NI0N 4 

4 O.SOOOOSHEEF 

63.99999APPLE 4 

,=275000.00000 

2.699990NI0N 4 

l.OOOOOONION 4 


2699.99998 
1 .OOOOOCOTTON 
l.OOOOOAPFLE 
65.00000COTTON 
SO.OOOOOCOTTON 
5,059999 , 99940 

90.00000COTTON 
32.00000C0TT0N 
= 15000.00000 

i.OOCOOCOTTON 
= 4000.00000 

2.00000C0TT0N 
= 5000.00000 

3.00000C0TT0N 
= 6000.00000 

1 .OOOOOCOTTON 
1*OOOOOONION 
1 .OOOOOAPPLE 
i.OOOOOORANGE 
3 .OOOOOCATTLE 
l.OOOOOSHEEP 


4 l.OOOOOONION 

4 l.OOOOOORANGE 

,= 200000.00000 
4 60.000000NI0N 4 

4 63.99999APPLE 4 

4 12.999990NI0N 4 

4 4.000000NI0N 4 

4 5.000000NION 4 

4 6.000000NION 4 

= 2000.00000 
= 250.00000 
= 500.00000 

= 800.00000 
= 400.00000 

= 300.00000 


0.40000SHEEP <=205000.00119 

50. OOOOOAPPLE 4 75 . OOOOOORAHGE 


85.000000RANGE 

1. OOOOOAPPLE 

1. OOOOOAPPLE 

1849.99999 

600.00000 

50. OOOOOAPPLE 

85.000000RANGE 

14.00000APFLE 

7. OOOOOAPPLE 

8. OOOOOAPPLE 

9. OOOOOAPPLE 


4 0.30000CATTLE 

4 1.50DOOORAHGE 

4 1. OOOOOORAHGE 

4 75.C00000RANGE 

.=269999.99880 
4 15. OOOOOORAHGE 

4 10. OOOOOORAHGE 

4 10.999990RAHBE 

4 12. OOOOOORAHGE 


LIST OF UAR1AFLE5 

COTTON 
ONION 
PF-F [ E 
OKANOL 
OATT L £ 

ShCEF- 

1 LIST or CONSTRAINT NAntS 

TOTLATERflA*^ 

TCTLATERJUNE 

TOTWATERJl'LY 

LftPORAOL 

TOIL AND 

FILDLAND 

ORTHLAND 

WATERAMLMAY 

WATERAOlJUNE 

UATERAULJULY 

RED VI ELD 

fertavl hay 

FERTAUL JUNE 
FERTAML JUlY 
CEIL COTTON 
CEIL ONION 
CEIL APPLE 
CEIL ORANGE 
CEIL CATTLE 
CEIL SHEEP 




Fig^ 5: Model Forniulat-iori in Expanded Forn: lor 

i4gricul’tur£.l Problem. 



industry; "Bakery Problem" representing product planning iirith 
multiple stages. These problems alongvith their LAMP formiula- 
tion are given in Appendix A. 

A ’'Help" file to familiarize a novice user is provided 
in Appendix B which contains an interactive session using 
LAMP. 

The detailed documentation listing the function of the 
various modules that constitute the LAMP system forms 
Appendix C. 



CHAPTER V 


STANDARD IHTERFACE FOR DaTA MANAGEMENT 

5.1 INTRODUCTIONS 

Tra.di'tionally ■the problem processors were rigid 
computer programs designed for the numerical solution only. 
Later they evolved into matrix generators and then modelling 
languages. Many of the mati'ix generators veve built around 
specific mathematical programming systems. It is generally 
true of modolling languages also. In order that the modell- 
ing languages/matrix generators can interface with problem 
processor, no standards are yet available. Traditionally 
in this area the input data representation employed by IBM’ s 
Mathematical Programming Systems Extended [92] has become 
a"de facto" standard. Unfortunately this standard is 
ancient and does not easily lend itself to further machine 
processing. We propose an alternate fomalism using a simpl 
relational vi<^w of the data. This view while acting as 'a 
standard also helps us significantly in the use of data 
management capabilities for other activities as well. Before 
we discuss the actual representations we take stock of some 
of thf: concepts of data base in general and relational 
systems in particular. 
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5.2 DATABASE MAl\TAGEMENT SYSTEMS 5 

Data Base Manag^iment Systems (DBMS) usually ara not 
thought as modelling systems by the OR/MS community ^ but they 
are all based on one or another data model [l64] than 
attempts to organize virtually all of the data needs of 
various models. The actual model employed, viz. hierarchical, 
network or relational is important in the design of the user 
interface. The additional requirements of quality, integrity, 
security and control of data, have far reaching effects on 
the overall cost, accessibility and performance of any data 
bitse management system. 

The data base management has the capability? 

. to make an integrated collection of data available 
to a wide variety of users; 

. to provide for quality and integrity of the data; 

. to ensure retention of privacy through security 
measures within the system; 

, to allow centralized control of the data base, 
which is essential for efficient data administra- 
tion; 

. to provide data independence. 

Database management systems have the attractive featui 
of introducing an indep'^ndt^nce between data structure and 
data manipulation. In the model management concept we 
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would like 1:o havp the structure of the model and the data 
independently kept and linked only at the time of actually 
running the model. This provides us an ability to retrieve 
and update data with an elegance and power that surpass 
qualitatively any matrix generator type software currently 
available. The support v;hich a modeller gets in such tasks 
as data validation and manipulation is truly remarkable, 
with the availability of DBMS Software. 

In database technology, the data definition generally 
consists of statement of the names of elements, their pro- 
perties (e.g., string or numeric type), their relationship 
to other elements which make up the database. The data defi- 
nition of a specific database is often called as schema . 

The schema provides the logical and physical structure. The 
logical structure describes the user^ s view of data. It 
deals with the named elements and their relationships rather 
than with tho physical implementation. The physical structure 
describes tho way tht data values are stored within the 
system. It deals with pointers, character representation, 
floating point and integer representation, signedAmsigned 
representation, record blocking and access methods. 

Logical data indopendenco represents the ability to 
make logical change to tho database without significantly 
affecting the programs which access it. Physical data 
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independence relieves user^ from providing informe.tion on 
details of the structure and allows dealing with different 
structures and/or different access methods. 

The logical structure which describes the user’s 
view is based on data model concepts which allows user to 
define relationship existing among different classes of 
objects. Prominent data models are hierarchical, network, 
and relational as discussed earlier. The general trend in 
database management is that users are becoming increasingly 
oriented toward information content of their data and less 
concerned with its representational details. Such trend 
away from representation details is knovjn as data indep endence 
Database management systems using hierarchical or network 
structure represent the information by having contents of 
records; the connections between records and the ordering of 
records. User queri'-'s made to the DBMS are then framed in 
terms which depend on user knovrledge of chosen representation. 
In the relational model, however, information is represented 
by data valiu.s only at tho user interface ► The usc-r queries 
become fre-f of any dependence on internal representation and 
may be frvimc'd in a high-level non-procedural language. At the 
same time, the system becomes free to choose any physical 
structure for storage of data and to optimize the execution 
of a given query. The various types of data models have 
their own advantages and disadventages. It appears that the 
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relational model is likely to be the most widely used model 
in the luture. It also has an attraction of an elegant 
structure and a strong theoretical foundo^tion. Hence we 
limit ourselves to r€:lational model in our work. 

5.3 RELATIONAL. DATABASE LIANACEMENT SYSTEMS S 

E.F. Codd 1.43] first suggested relations (tables) 
as a tool for database management in 1970 and defined 
rigorously n-ary relations (i.e., tables having "n” columns 
representing "n" attributes.) in the database context. He 
emphasized their advantages for data independence and 
symmetry of access. Codd’s work introduced concepts which 
set the direction for research in relational database manage- 
ment in later years. The paper [ 43j defined a data sublanguage 
as a set of facilities, suitable for embedding in a host 
programming language which permits the retrieval of various 
subsets of data from the database. He recommended the first 
order predicate calculus, a logical notation to bo an appro- 
priate data sub language for n-ary relations. The paper 
rclso intro due. a a sot of operators ("ooin”, ’’’projection", 
'’selection", etc.) which were later developed into the well- 
known relational algebra. Finally, the paper es^lored the 
properties of ''redundancy" and "consistency" of relations 
which laid the ground work for Codd's later theory of 
"normalization". The basic concepts and definitions under-- ; 
lying the relational data model are summarized below. 
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Mathematically, the term relation may he defined 
as» Given sets D^, (not necessarily distinct), 

^ relation R is a subset of n-tuples each of which has its 
first element from second element from etc. The 

sets are called domains . The number "n" is called the 

degree of R, and the number of tuples in R is called its 
cardinality . 

It is customary to represent a relation as table in 
which each row r(.'presents a tuple. In the tabular represen- 
tation of a relation the properties to be maintained are* no 
two rows Tire identical; the ordering of rows is not signifi- 
cant and the ordering of columns is significant. In a "rela- 
tion" represented as a table, the number of rows is its 
cardinality and the number of columns is its degree. For 
tabular representation of a relation it is customary to 
name the table* and to name each column. The columns (fields) 
of the table arc called attributes . In relational theory 
the terms referred as "relation", "tuple" and "attributes" 
arc gent rally referred also c.s "table", "row" and ''columns" 
(fields) respectively 'for relational applicottions. The 
individual entries in each tuple are called its components . 

A column or set of columns (attributes) v/hos's vcRues uniquely 
identify a row of a relation is a candidate key (generally 
called a key) of the relation. Ifl/hen va relation has more 
than one field as key, it is conventional to designate one 
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as the primary key and the other as the secondary key . The 
term data model represents the complete set of relations 
stored in the system. A Schema is a set of declarations 
that describes the data model and a subschema is a set of 
declarations that describes some part of schema available 
to a particular user or a group of users belonging to some 
category. The design of schema and subschema for a database 
is closely related to the concept of normalization which is 
primarily based on features of functional dependencies between 
attributes of a relation. 

Functional dependencies are the main features of 
relational schemes. But it introduces undesirable anamolies 
in relational scheme, i.e., if an attribute value is updated 
in one of the relations, its effect on other relations may 
not be validated on its own. This fe-'.ture was first recog- 
nized by Codd c-md he suggested the concept of normalized 
relations to avoid or atleast minimize the effect of above 
anamoly. The underlying principle of normalization is to 
replace the initial bigger schemes by several smaller schemes 
using non-loss decomposition principle as there exists a link 
between functional dependency and decomposition. 

Normalization theory is based on the observcition 
that certain collections of relations have better properties 
in an updating environment than the other collections 
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of relations containing the very same 
data do. The normalization theory then provides a strong 
foiindation for the design pf relations which hav? favourable 
update properties. The theory is based on series of normal 
forms (NF) — first (iNF) to third (3NF) and recently to 
fifth normal form (5NF) — which provides successive improve- 
ments in update properties of database and thus minimize 
insertion, update and deletion anamolies. The most v/idely 
known result of normalization theory is third normal form 
often known as 3 '^oyce-Codd Normal Form" (3BCNF), 

The various normal forms can be briefly described as[50] i 
First Normal Form s 

A relation is in first normal form (iNF), if every 
component (field) of each tuple (i.e., row of a table) is non 
decomposable (atomic) i.e., fields must not contain repeat- 
ing groups. 

Second Normal Form s 

A relation is in second normal form (2NF) if all 
non key attributes (fields) are fully dependent on keys 
i.e., every non key field of first normal form be dependent 
upon the complete primary key. 
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Third Normal Form s 

A relation is in third normal form (3NF) if all 
non key attributes are directly and fully dependent on keys. 
The third normal form (3hF) requires, second normal form 
tables to be decomposed, if a non key field determines yalue 
of another non key field i.c., transitiye~dependencles 
should be eliminated. 

Fourth Normal Form o. 

The fourth normal form (4NF) requires that third 
normal form (3i'^F) tables should not contain tv/o or more 
independent multiyalued dependencies. 

Fifth Mormal Form s 

The fifth normal form (pNF) requires that fourth 
normal form (4NF) tables should not be nonloss decomposed 
into three or more smaller tables. [54] 

In context of relational schemes, nonloss decompo- 
sition means that there is no loss of information due to 
decomposition of a relation into seyeral relations. A non- 
loss decomposition guarantees that the join produces exactly 
the same original relation. The technique of nonloss decom- 
position proyides an aid to the relational database design. 
The basic approach consists of starting with some giyen 
relation, together with a statement of certain constraints 
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in the form of functional dependencies and multi valued 
dependencies. They are successively decomposed to a collec- 
tion of relations that are equivalent to the original rela- 
tion and yet are in some way preferable to it, using the 
constraints to guide- the reduction (decomposition) stages. 

Relational schemes giving rise to design of relations 
(tables) have follov/ing major advantages. 

Simplicity -. 

The relational user is presented with a single, 
consistent data structure. User formulates his query strictly 
in terms of information content, without any reference to 
system oi'icnted details. 

^ata Independence ii 

According to Date (.50] the data independence is 
defined as "immunity of applications to change in storage 
structure and access strategy." The relational model makes 
it possible to eliminate the details of storage structure and 
access strategy from the user interface. 

Symmetry ^ 

Data base systems which are based on connections 
between records make some questions easier to ask than others 
viz. questions whose structure matches that of the data base. 
Since all information is represented by data values in 
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relations, there is no preferred format for a question at 
the user interface. It should be noted here that the symmetry 
of the data model does not necessarily imply S3mimetry of the 
associated physical data structures maintained by the system. 

Strong Theoretical Foundation s 

The relational data model rests on the well developed 
mathematical theory of relations and on the first order pre- 
dicate calculus. This theoretical background makes possible 
the definition of relational completeness, and the rigorous 
study of good data base design (normalization) . A language 
is said to bo rolationally complete,^ if any relation derivable 
from the given relations (i.e., the database) by means of 
expression of the relational calculus^ can ba retrieved using 
thc-^t language. 

The other important advantage is the eas^ of use with 
which high-level, non-procedural relational languages may be 
defined. Because they are easy to learn and use, high-level 
languages make databases available to a new class of casual 
users who lack the training required by conventioncO. programming 
languagi^s. High-level langu-agts also give the system maxi- 
mum flexibility to optimize the execution of a given query 
■and to adapt the stored data structures to the changing needs 
of the ust r population. The non-procedural approcxch to 
language design permits a unified treatment of data definition, 
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data, manipulation and control. Moreover, high“leval languages 
make it easy, to define and manipulate views of data which are 
not directly supported by physical structures. Though some of 
the above advantages are common to other data models as well, 
the database management systems based on the relational 
data model approach have been the most extensively researched 
models in the recent years. The reasons are many; the chief 
among them being their elegance, versatility and power. 

5.4 INTERFACE DESIGIh 

In order to achieve the data independence and flexible 
access wc first view the input data and output vaRues of 
standard linear prognanming problem as a set of normalized 
rel tions. Moreover, to capture all essenti:.! information 
pertaining to input data thcs<i relations h'- ve been designed 
accordingly. The following set of eight relations are capable 
of capturing all necessary information related to the input 
data needed in any linear programming problem. 

(i) ivar ~ the list of variables 

(ii) icon - the list of constraints (including the 

objective function as the first constraint. 

(iii) ivarn - the list of variable names 

(iv) iconsn- the list of constraint names 

(v) ivarlb- the lower bounds (if any) 

(vi) ivarub- the upper bounds (if any) 
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(vii) imat; - "the coefficienl: matrix elements (non“zei’o 

values only) 

(viii) iconsd ~ the constraint detail (type and RHS value) 
The structure of these relations is as follows^ 


(i) 

ivar 

0 

0 

(Var__id) 

(ii) 

icon 

0 

0 

(Cons_id) 

(iii) 

ivarn 

0, 

(var__id ' , var__name ) 

(iv) 

iconsn 

0 

p 

(cons_id'^, cons__name) 

(v) 

ivarlb 

o 

o 

(var__id'*', lower_bound) 

(vi) 

ivarub 

4 

(var_id'*', upper__bound) 

(vii) 

imat 


(cons_id*'', var_id'*", mat__element) 

(viii) 

iconsd 

4 

(cons_id’^, cons_type, rbs value) 


NOTE; (a) Underlined field (s) constitute the key of the 
relation. 

(b) "+ "indicates that the key is linked to a base field. 

This linking with the database field leads to mini“ 
mization of deletion and update anamolif- s in the relational 
datov base mode] , 

The solution values of the linear program can also 
be viev/od as a sot of normalized relations. The following 
set of four rel^'tions are designed to capture all necessary 
information related to solution of a linear program. 
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(i) 

ovar - 

solution values 


(ii) 

ocon 

constraint values 


(iii) 

objr 

cost range 


(iv) 

orhsr ~ 

rhs range 


The 

structure 

of these relations is as 

follows;. 

ovar 

; (var 

^id"*", solution, relative^ 

_co st ) 


(i.l) ocon '» (cons_id’^, slack, dual“price) 

(ill) objr - (var^id”^, current^cost*, cost- increase, 

cost-decrease) 

(iv) orhsr i (cons_id’^, current_rhs*, rhs_increase , 

rhs--decrease) 

The type and format of the fields for both the input 
and solution models arp’ summarized below» 


(a) 

var_id 

string 

of length 

8 

(b) 

cons_id ; 

string 

of length 

7 

(c) 

var_name ; 

string 

of length 

32 

(d) 

cons name ; 

string 

of length 

32 


(e) all other fields are numeric of float t3rpe (l3,6) 
i.e, , thirteen digits long numbers with six 
digits to the right of the decimal point. 

NOTE; Those formats are compatible with MPS format [ 5'2J . 

Some of the queries necessitate storing the results 


of a query for which temporary relations i.e. ofunct and 
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"orhfunct" have been incorporated in the schema design of 
interface database. The structure of these relations is as 
follows s 

ofunct i ( ?vofun „ ovl, oflj of2j of3s of4s ofb) 
orhfunct ^ (Krhfun, rcl, rfl, rf2, rf3j rf4, rf5) 

Using proposed schemes for a set of input relations 
as well as a set of output relations the actual design of 
relational database is done by UIniIFY DBMS package implemented 
on UhlX based machine UPTROU S-32 at IIT Kanpur. Further the 
problem solver LliNiDO is used to solve the model formulation 
done by modelling language component of LAMP. For an introductory 
precise reference to novice users, the specific features of 
the problem solver LINDO is given in Appendix D. The perti" 
nent information about Ui'lIFY package for user acquaintance 
is given in Appendix E. The salient details of the data 
manipulation language uajlJ'nStKi'^: to UNIFY DBMS package- (i.e., 

SQL) is given in Appendix F. 

Once the solution to model formulation is done by 
LINDO, several soteof interface programs transfoim the model 
formulation data as well as solution data in a format acc-jp- 
tablo to the database (i.e., in accordance with schemes pro- 
posed above). Using any appropriate utility to enter the 
data to database, the data entry to relations is achieved. The 
schema report listing for input relations as proposed is given 
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in Figure 6. The schema report listing for the output 
associated relations is given in Figure 7. The set of input 
and output relations data generated for agricultural planning 
sample problem, as described in Section 4.4.1 is shown in 
Figure 8 and Figure 9 respectively. Thus the interface 
module has been suitably designed to capture all relevant 
information necessary for a linear programming model. In the 
next chapter we discuss the detailed data analysis capabili- 
ties of LATiP. 





» »' NOTE ; Lines startins with are 'Co»ii.ent' lines. 

» INPUT RELATIONS 


SCHEMA REPORTS 
Scheiiis Listings 


^ 

RECORD/riELD 


REF 

TYPE 

LEN 

LONG NAME 

1 vai 

100 




var_I 1 st 

ivar 



STRING 

8 

var^id 

acori 

100 




cons-l ist 

icori 



SIRING 

y 

cons-id 

1 Vo T ri 

100 




var-»nsnie_l ist 

j Vo rn 


F 1 var 

STRING 

8 

var^id 

Vo T rjante 



STRING 

32 

varans me 

2 cori&n 

100 




cons_n3nie_l ist 

1 conn 


k icon 

STRING 

7 

cons-id 

consnanjc 



STRING 

32 

cori5-.nanie 

a V c r 1 1 

50 




var_I ower >«boijnd 

il 


[ IVoT 

STRING 

8 

vaT_id 

It 



FLOAT 

136 

lower.>bound 

I Vc T Ut' 

50 




var^ijF F er_bo'jnd 

1»J 


i vsr 

STRINC- 

S 

V c r _ 1 d 

ut 



riOAT 

1 36 

UF Per -bound 

J. C 0“**: C 

2(0 




cc'fis -ceieii 

a cone 


t 2 cor, 

STRING- 

7 

cons-id 




STRING 

1 

cons-typ£ 

rhvol 



FLOAT 

136 

rhsvc lue 

in-c t 

500 




nistr in 

3^^ in»at 



COKP 


in»3t 

f iconni 


!■' icori 

STRING 

-*> 

/ 

cons-id 

^ avarn. 


k I var 

STRING 

8 

var-31 d 

n<ot vsl 



FLOAT 

136 

Hfc t-elc-merit 


Note; Starred field (s) indicate'?'' 


- - r 1 p - 


Fig. 65 Schema Listing for Input Relations. 


cns. 
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« II KDTE : Lines startins with are 'Comment' lines. 
» OUTF'UT RELATIONS 

SCHEMA REFORTE 
Schema Listing 


* 


record/field 

REF 

TYPE 

LEN 

LONG NAME 

over 

ovc* r 

100 

F 1 var 

STRING 

S 

V8 revalue 

Vc r...id 

ovbI 


FLOAT 

136 

solution 

rcost 


FLOAT 

136 

relative-.cost 

ocon 

100 



cons^^val UP 

*1^ ocon 

kicori 

STRING 

7 

cons- id 

sval 


FLOAT 

136 

slacl^ 

dp n ce 


FLOAT 

136 

dual -price 

ObJT 

100 



cosi-rartSc 



CONB 


F obu 

}• Ob JT 

F 1 var 

STRING 

e 

var-id 

ccof 


FLOAT 

136 

cur rent-cost 

OCSl 


FLOAT 

136 

cost-inc rease 

ocsd 


FLOAT 

136 

cost -decrease 

orhs r 

100 



rhs-T anse 

orhs 


COMP 


F orhs 


For hs r 

^ XCOTi 

STRING 

7 

cons-i 0 

c v-c T 


FLOAT 

136 

rurr ent-rh? 

r h v c 1 


FLOAT 

136 

rhs-inc t eas e 

I « C 0 0 


FLOAT 

1?6 

rhs- oes rease 

C' f U ' 1 c t 

10: 



of urirt 

of Ul* 


STRIrvC 

E 

F of urj 

0 ^‘1 


STRING 

E. 

0‘v 1 

of 1 


FLOAT 

136 

of 1 

of 2 


FLOAT 

136 

vfZ 

cf3 


FLOAT 

136 

of 3 

of A 


FLOAT 

136 

of^ 

oft 


FLOAT 

136 

ofS 

orhf ufic t 

100 



orhf unct 

si* f T hf uri 


STRING 

7 

F rhf un 

r c 1 


STRING 

7 

rcl 

rf 1 


FLOAT 

13L 

rfl 

rfC 


FLOAT 

136 

rf2 

rf 3 


FLOAT 

136 

rf3 

rf4 


FLOAT 

136 

rf^ 

rfO 


FLOAT 

136 

rfO 


I;ote: 


Starred field(s) indicate (s) key(s) of relations. 


Fig. 7; 


Scheir.a Listing 


for Output relations. 
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» M note : Lines stsrtins with are 'Coi..mer.t' lines, 
» SAMPLE INF'UT RELATIONS FOP AGRICULTURAL MODEL 

vaT_id 


SHEEP 

CATTLE 

ORANGE 

AFPLE 

ONION 

CCTTDN 


cor s-a r, 


21 

20 

JV 


iA 

IG 

12 

13 

10 

9 

E 


c -<= ». 1 c J cc*rj«r »nan.: 


2 1 

;ctiL 

EhTEf 

20 

3 Ct IL 

C^'TILE 

19 

3EE2L 

Of r.NOE 

16 

3CLIL 

APFLE 

17 

5CE1L 

ONION 

Ic 

JCEIl 

GDI TON 

IZ 

J FERTAUL 

JULY 

lA 

3 FERTAOL 

JUNE 

13 

JFERTAVL 

MA't 

12 

IREO^flELIi 

11 

J WATERAULJULT 

10 

I WATLRAULJUNE 


9 JUATEFAOLhAr 

;ORCHLANL 
iPIi DLANr 
noiLANr 
JLABORAVL 
I TOT WATER JUI Y 
••TOTWATERJUNf 
JTOTWATERHAY 


Sample 
Model , 


Input Relations for 
(Contd. ) . 


Ag ric Tilt ural 
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» II NOTE : Lines starting with sre 'Comment' lir.es 

SAMPLE INEUT RELATIONS FOR AGRICULTURAL MODEL 

*****-************^*%**».%^t*.X**M*.%***%*i7t.*.*>]l.*,^*.W* 


cons-id I cons-tyFe I rhsvalue 


21 

!L 

I 300*00000 

20 

JL 

I 400*00000 

19 

IL 

I 800*00000 

le 

!L 

I 500*00000 

17 

IL 

I 250*00000 

16 

IL 

I 2000*00000 

15 

IL 

I 6000*00000 

14 

IL 

I 5000*00000 

13 

IL 

I 4000*00000 

12 

IG 

I 15000*00000 

11 

IL 

I 269999*99381 

10 

IL 

I 259999*99940 

9 

IL 

I 200000*00000 

8 

IL 

I 600*00000 

7 

IL 

I 1849.99999 

6 

IL 

I 2699*99999 

irj 

IL 

I 5850*00002 

A 

IL 

I 275000*00000 

3 

IL 

I 265000*00060 

n 

I L 

I 205000*00119 

cor 

s-idivsr-io' I 

niot_elenient 

21 

ISHEEF I 

1*00000 

A 

ISHEEF I 

0*60000 

3 

ISHLEF I 

0*50000 

2 

ISHEEF ; 

0*40000 

1 

ISHEEF I 

719*99998 

20 

ICATTLE 1 

o 

e 

o 


ICA7Ti.E I 

C *30000 

3 

I C A7 7 i» E i 

0,2000C 

2 

ICA-IlE 

<•, lOOCC 

1 

ICAT7lE I 

6C'0 *00^^00 

19 

lOF.AHBE 

1 * OOOOG 

15 

I ORANGE I 

12*00000 

14 

I OFvhNBE I 

10*«^^99?9 

13 

I0F.AN2E I 

10*00000 

12 

1 ORANGE I 

15*00000 

11 

I ORANGE ; 

85*00000 

10 

I ORANGE 

75*00000 

s 

lOFANGE I 

1*00000 

6 

I GRANGE I 

1*00000 

5 

I ORANGE I 

1*50000 

4 

I ORANGE I 

85*00000 


Fig. 8: 


Sample Input Relations for Agr 
Model, (Contd.). 


. ( cont iriupd ) 




iculxt^al 
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n »» NOTE : Lines starting with "3^^ are "Comment' lines* 
t SAMPLE INPUT RELATIONS FOR AGRICULTURAL MODEL * • . . < cor.ti nued ) 


coris 

_id ! var« 2 d 

rnat-.elemeni 

3 

J ORANGE 

75*00000 

1 

I ORANGE 

8812*99996 

18 

i APPLE 

1*00000 

15 

.‘APPLE 

9*00000 

lA 

1 AF’PLE 

8*00000 

13 

.■APPLE 

7*00000 

1C 

; AP’PLE 

14*00000 

11 

1 APPLE 

63*99999 

10 

; APPLE 

50*00000 

8 

1 APPLE 

1*00000 

6 

{ AP’PLE 

1*00000 

5 

.‘APPLE 

1*00000 

4 

J APPLE 

63*99999 

3 

t APPLE 

50,00000 

1 

1 APPLE 

481^*00013 

17 

! ONION 

1*00000 

15 

J ONION 

6.00000 

lA 

J ONION 

5,00000 

13 

J ONION 

4*00000 

12 

JONION 

12 * 99999 

10 

ION JON 

60*00000 

coris 

„ ad I veT_io 

mat ..element 

y 

iON’icu ; 

1 *00000 

6 

JON I ON 
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60*0000r. 

1 
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j t 

J C C T Of" 

1 ,00000 

It 

ICOTTON 

3,00000 

1A 

; CDTTOn 

2,00000 

13 

J COTTON 
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12 

J COTTON 

12*00000 

11 

: COTTON 

90,00000 

10 

; COTTON 

80,00000 

9 

JCOTTON 

65,00000 

"Mr 

/ 

J COTTON 

1,00000 

6 

J COTTON 

3 *00000 

5 

J COT TON 

2*90000 

4 

.■COTTON 
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3 

J COTTON 
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o 

J COTTON 

65,00000 

1 

i COTTON 

6453*00007 


Fig. 8: Sample Input Relations for Agricultural 
Model. 
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* " NOTE : Lines stertins with ere 'Com8.ent' lines. 

* SAMPLE OUTPUT RELATIONS FOR AGRICULTURAL MDI'Ei. 

» **»»*»»*»*»**J^*»*»*»»*!t-*#*»'*ll******»»!|t»,***#»»»»*, ■ 


var,.id 

1 solutiorij 

relati ve^cost 

SHEEF 

! SCO. 000001 

0*00000 

CATTLE 

1 400*000001 

0*00000 

ORANGE 

1 37*500001 

0*00000 

‘APPLE 

J 0*000001 

1795,74990 

ONION 

1 0.00000: 

2546.C5:.10 

COTTON 

: 1849*999991 

0.00000 

cori£-i d 

Sl3C^ 1 

dU 0 l_Pr 3 .Ce 

21 

0*000001 

719.99998 

20 

c.ooooo; 

600*00000 

19 

762*500001 

0,00000 

18 

500*000001 

0,00000 

17 

250*00000! 

0*00000 

16 

150*00002! 

o*ocooc 

1C 

0*00000! 

734,41666 

14 

887*50036 ! 

0 * 00000 

13 

1775*000001 

0*00000 

12 

7762*49981 1 

0,00000 

11 

100312*50268! 

0,00000 

10 

109187*503161 

0*00000 

9 

79750*002031 

0*00000 

8. 

562*500001 

0*00000 

/ 

0*000001 

4249*75('34 

6 

812*500001 

0*00000 

•r 

w> 

42£' • 74990 ; 

0*00000 

A 

105012*50327 I 

0*00000 

*3, 

113957*503441 

0*00000 

2 

84590,002301 

0*00000 


v‘ £ r _ jL u 

1 cur T erit_coi: i 1 coc t_incrc 3 £e 

CDst_dec reese 

SHEET 

1 719*<=^9^9£ 

T J 000000 ^ ^ 

71 9 * 99998 


1 600* 00 00 C 

J OOCOOO ^ 


6 CC, OOOCO 

OT, Af'*G[ 

' £ E 1 3 * 0 C' OZ 2 1 1 6 ^ 9 *^‘ * C 0 0 0 3 


23=-'4,3Z33C 

AFFLE 

48:4,00013! 1^95,"‘4^'°C ; 

999=^’9£ *99864 

OHIO, 

. 6111. OOOZ 

, 254c * 250 1 C 

CQ'poorj ^ 0 c c .. A 

COTTON 

1 6453*0000: 

^1 999998, 99864 

2546 * 25010 

cons -id 

cur renter hs 

r n^-iriCT east 

rhb-dec ree:ifc 

21 

iivL‘*CGv^UO 

175020,83033 

300*00000 

20 

400*00000, 

350041 *66067 

400*00000 

19 

800*00000 

999993*998d4 

762,50000 

16 

500 * COOOO 

999998,99864 

500,00000 

17 

250 * 00000 

999^98,99864 

250 ♦ 0000 v‘ 

16 

2000 , OOC 00 

999998*99864 

150*00002 

1 5 

6000 * 00000 

908,18311 

450,00000 

14 

5000*00000 

999970, 99S64 

887*50036 

13 

4000 * 00000 

999998,99864 

1775,00000 

12 

15000*00000 

7762*49981 

99=^*998*99864 

11 

269999*99861 

9 9=^95 5*99864 

10C-3i2.50Cc,8 

10 

25997 7 * 9 9 9 4 0 ! 

999996, 99oo4 

109157*50316 

9 

200000 * 00000 1 

97V99£,99oo4 

79750*00203 

e 

600**000001 

999996,99864: 

562.50000 

7 

1S49*999£9: 

150,00000 

940,90907 

6 

2699*99999 , 

999998, ==‘9864 

812* 50000 

5 

5850 * 00*002 ! 

999 7 98 , 9=^o64 

428*74999 

4 

275000,00000 

999998,99861 

105012*50327 

3 

265000* ♦ OOOcO 

999998.99864 

113957 *50ci44 

2 

205000 ,00119 

999998, 99864 

64590 * 00230 




Fig, 9: Sample Output Relations for Agricultural 
Model . 



CHAPTER VI 


DATA MAIMACEI'IENT ASPECTS OF LAMP 

6.1 INTRODUCTION^ 

Most real life LPP’s tend to be of reasonably large 
size involving several thousands of variables and several 
hundreds of constraints. Obviously, one has to ensure that 
each and every coefficiert that goes into the model is correct 
both in its value aid its association with appropriate variable 
and constraint. This is definitely not a trivial issue. The 
early matrix generators used several utilities to perform 
this task. Routines for the above basic task have been incor- 
porated in PERUSE [U-O] and sophisticated testing routines to 
reveal common errors have been incorporated in AI'jALYzD [82] . 
Substantial portion of mathematical programming software like 
MPSX [ 92 ], LINDO [1^5] is devoted to the job of data validation. 
Data validation which is the part of model validation ensures 
the exact value of data used in algorithmic form in plact of 
coefficients and right-hand- side values in the form of identi- 
fiers and parameters of the modeller’s form. 

Modelling languages incorporate distinction between 
symbolic and explicit forms of data and thereby offer more 
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flexible and more convenient management of data than the 
common matrix-generation language. S;^rmbolic representation 
of data also promotes reliability by serving as a check on 
validity of explicit data. The modelling language translator 
can detect explicit data that are not specified in conformance 
with the modelling language symbolic representation. 

The modeller needs help in the presentation of results 
v/hich again become voluminous. Report-writer programs devoted 
to this task have been appended to the standard mathematical 
programming software. The LP solver generates an optimal 
basis. But the modoller/user wants to know the optimal acti- 
vities and other solution values. Thus any linear programming 
system needs ways of storing and retrieving both input data 
and solution values, extracting solution data to make readable 
reports. Both the tasks viz. d^ta validation and report writ- 
ing act as heavy overheads on the problem solving software. 
Based on the solution of the model, usually the modeller may 
have some query. In addition, detailed "whax if" analyses that 
are mandatory in any modelling activity require an ability to 
modify the data und the structure and re-solve the problem, 
interactively . 

A modelling language provides the modeller with a 
medium to express the model structure to a model manage- 
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merit system, which in turn generates the detailed model 
data for the problem processor. To support the raodeller 
in the interactive editing, report v/riting and "whau if” 
analysis stages we need a similar medium for expressing 
the model manipulation function. We initialljr planned 
to design a language that provides model manipulation 
capability. A closer look, however, revealed the fact 
that the manipulation of the structure can be handled 
using thf‘ model language itself in association with a 
standard text editor. Other manipulations primarily amount 
to data manipulation and the well developed theory/ of 
relational databases and a query language based on a rela- 
tional system should be able to provide this capability 
directly. Of course, this would mean an abiliti^" to inter- 
face modelling language with a query language. The rela- 
tional view of the linear programming problem precisely 

i Y« |>€em «n !"«=l 

provide such an interface. We the idea by 

interfacing LAMP wit}i a relational system UNIFY [l68] which 
supports a query language SQL l95]. 

It turns out that our con;iecture is in fact true, 
as v/e demonstrate it in detail in the following sections. 
Thus we managed to exploit the rich capabilities of the 
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query langusge v/ilhout; dGsigning anoi^her language for model 
manipulation. Additionally the ideas we demonstrate are 
general enough to be of value in other application areas 
as well. 

6.2 Data AJ^JALYSISJ 
6.2.1 Introduction ! 

A relational view of the input data and solution values 
enablesus to exploit the power of the relational DBMS software 
to assist the analyst in the different aspects- of the modelling 
process. Various kinds of "sensitivit 3 ’’"and ’'what if" analyses 
can be performed in a flexible manner. Ever^?- relational DBMS 
softv/are supports a q-aery language which is non-procedural. 
Non-procedurality allows the analyst/modeller to view the task 
v;ithout getting involved much in the details of hov/ exactly 
the task must be translated into a set of procedures. The actual 
procedure conversion can be conveniently left to the machine, 
thereby peiinitting a rneta-level interface betv/een the modeller 
and the machine. Most of the query languages have the property 
of relf^tional completeness i.e., any quer}/ of arbitrary com- 
plexity concerning the database can be written with the help 
of the query languages. Also most query languages support 
user friendly interfaces for interactive editing, report 
writing, data entry, etc. Such an environment facilitates fairly 
complex analysis, to be performed with ease. 
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UNIFY, a relational database management system software 
which has been implemented for data management aspect uses 
Structured Query Language (SQL). SQL permits "select", 

"from", "where" constructs for simple queries. It further 
allows nesting, arithmetic computations, delete, insertion 
and update features to build desired queries of ■var 3 ^ing com- 
plexities. UNIFY also has embedded "SQL by Forms" based on 
the Query-By- Example (QBE) approach. In addition it has a 
listing processor (LSI) and a report processor (RPT) which 
can presf’nt and produce formatted reports based on results 
of query as desired by an analyst/user. Typically most of 
the current generaition relational DBMS provide similar capa- 
bilities. 

SQL is emerging to be one of the most popular query 
languages. Data analysis for various information related to 
real world problem model can be done using SQL. ¥e illustrate 
this idea in following subsections. For the sake of clarity 
we classify the analysis into three stages viz. , 

(i) Input Data Analysis 

(ii) Solution Report 

(iii) "What-if " Analysis 

6.2,2 Input Data Analysis * 

The modeller/analyst may like to verify all possible 
coefficient and right-hand- side values that go into the 
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model as input data. Further, based on them he may like to 
have information pertaining to problem statistics^ problem 
summary, simple error checking, consistency checking and sophis- 
ticated checking. Each of them is discussed separately. 

(i) Problem Statistics ^ 

Statistics like the count of variables, count of cons- 
traints of different type, nonzero coefficient count, density 
of the matrix, etc. can be conveniently obtained using SQL. 

Such gross measures provide a preliminary level of check and a 
rough idea of complexity of the numerical solution of the prob- 
lem. Sample query (Q;i) in Figure 10 illustrates these features. 

In the first query (Qsi.l) the "select" verb uses aggre- 
gate function "count*" to obtain the total number of records 
(i.e., number of variables) from the input relation var_list 
(ivar). 

Similarly the second query ( Q « 1.2) finds the total 
number of records (i.e., number of constraints) from the input 
relation cons_list (icon). 

In the third query (Qol.3) the ''select" verb obtains 
the total number of such records whose constraint type is less 
than equal to ( " < = " or "L" ) in the input relation cons_ 
detail (iconsd). The "where" clause specifies the required 
condition. 
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» >1 NOTE ; Linefr startins with are 'Comaent' Imei. 


)». < D:1 Frobleni stBtastics > 

^ y 


t -T Q 1 1 • 1 •^♦No of variBbles> 

select count ()^> fron. iver/ 

3^. -C Q:1*2 ♦**Ko of constrsints> 

select count (Jk") fron: icon / 

% -C Q : 1 3 4 * * N j of = const T SI nts > 

select count (*) front iconsd where cons_tspe= ' L ' / 

% < of nonzero coef f icients> 

select count from imet / 

I < 0 t i * 2 . 4 * No of urat coefficients? 

select count ()> ) from imet where met ♦ irtst-elen.ent ~1 ' 
“f G : 1 . 6 . ♦ . he t r 1 ? oens 2 1 s > 

delete of urict ' 

ar.tc of unc t M rf ur. ) J 'n.eider 
u-d£t<r cf jrnt set efi- select CDjr.zOf' fron irex^ 
w!-«ere 1- of uri= 'notoVn)^ '/ 

ur-deit ofurtct set of 2= select count fron ivsr? 
Wihere kof un=^ 'n.stden^ ' ^ 

uedeie ofunct set of3= select courtt f ron icon? 

where F of un^'nistderiJt " / 

uJ^deic- ofunct set of 4=of 1 / ^of 2*Df 3 ^ 

»*-* re of ur »= ’’ r» e t der»^ ' ^ 
select I* o^urif of 1 ?of2f of3?of4 fron. ofunct 
whs- re Fofun = ' metdefi^f ' / 


Fig, 10: Queries for Problem Statistics 
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The fourth query (Q»l,4) obtains the total number of 
records from input relation matrix (imat). This will be the 
total number of nonzero coefficients as input- r election matrix 
(imat) initially stores nonzero coefficient values only. 

In the fifth query (Qi 1,5) the "select" verb obtains 
the total number of specific records from input relation matrix 
(imat), using "where" clause specifying the required condition 
(i.e., only those records for v;hich the coefficient values 
are \mity). 

The query set (Qil.6) uses several queries to find the 
matrix density of LP matrix stored in the data base. In order 
to compute the matrix density the output relation (ofunct) is 
initialized by deleting all its previous records and fields. 

The key (kofun) of relation (ofunct) is set as "matden* " . 

Then the field " ofunct -ofl" for record having key as "matden*" 
is set equal to the valu^-' obtained from another query block 
which finds the total number of nonzero coefficients in the 
input relation matrix (imat). Similarly the field "ofunct. of2' 
is set equal to total number of variables for an input record 
with key as "matden*". Next query block updates the field 
"ofunct. of3 " with a value equal to total number of constraints 
for an input record v/ith key as "matden*". Next query block 
updates the field "ofunct. of4 " with a value equal to required 
matrix density which is computed using previously stored values 
corresponding to an input record with key as "matde-n* " . 
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Finally "tihe result is displayed by selecting vj.rious fields 
and result from the relation (ofunct) having key as "maiden-' 

Thus Figure 10 illustrates queries representing "Problem 
statistics" features associated with a linear program. 

(ii) Problem Summary ^ 

Sometimes the analyst/modeller may be interested in 
input data summary only. An ordered list (in any specific 
order) of variables, constraints, variable names, constraint 
names, right-hand- sides, bounds, smallest and largest elements 
in matrix, etc. can be obtained to enable a neat summary of 
the problem data. Sample query (Q»2) in Figure 11 illustrates 
these features. 

In particular, in the first query (Qsp.l) the "select" 
verb obtains all the constraint names (cons_name) from input 
relation cons_name_list (iconsn) and displays them in ascending 
order of constraint names. 

In the second query (QsS.S) all the fields of input 
relation var__upper_bound (ivarub) is displayed in descending 
order of upper_bound values. 

In the third query (Q:. 2.3) the first query block obtains 
the smallest coefficient value from input relation matrix (imat) 
and the second query block obtains the largest coefficient 
value from the same input relation matrix (imat). 



note: 


: Lines starling with ere 'Comment' lines. 

< Qir Problen. suJunicsry > 

^ y 

< Q12*1 Lisi of coristraint n 3 n.es iri sscendinS order > 

select coris^nsH'e 
fron. acortsn 

or do: bt coris_ncn»e ssc^' 

Q*2nZ %*. List of t*c*unds iri descendipsr order > 

select ^ 
f T oni 1 v3 rub 

order bs UFFer^bound desc/ 
r Q12*2 «,*Sn. 5 ll€ = t 3rid lersest elenieni in nietr ir > 
select n.iri Ciriet-.el en erit ) 
f ron met 

u.^l€•rt n ct^el en.ertl 0 ^ 

St ltd f. c ; <n.st-eiement ^ 
f T c'f in.c t 

where n.c t-eleoient ' 0/ 




Fig. 11: Queries for Problem Summary-, 
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Ihus Figure 11 provides sample queries representing 
"Problem Summary" features associated with a linear program. 

(iii) Simple Error Qiecking/Consistency Checking s 

Model validation requires model to represent the real 
life problem exactly. The input data v^'lues should be properly 
associated with variables with reference to a specific cons- 
traint. Minimal consistency checks are provided by the rela- 
tional model directly. For example, the linking of the key of 
the input relation matrix (imat) with the key (kivar) of 
var_list (ivar) and key (kicon) of cons_list (icon) automati- 
cally ensures that the matrix elements are defined only for 
valid variables and constraints that are already available 
in (i.e., known to) the^ database. Checking for a variable 
that does not huve nonzero coefficient in any constraint and/or 
a constraint with no nonzero coefficient corresponding to any 
variable can provide a simple error check. Such errors easily 
creep in many of the large scale problems due to a variety of 
reasons, i^so one can easily check for any constraint (s) with 
till zero/negative coefficient with a positive right-hand- side 
(RHS) element , which indicates a serious inconsistency. 

Saraple query (Q»3) Figure 12 illustrates these features. 

In the first query (Q;3.l) the inner query block first 
obtains the list of variable identifiers (var_id) from input 
relation matrix (imat) for which the coefficient value 




» I' NOTE : Lines stsTtins with are 'Comment' lines. 


t < Q^3 .♦* Simple error checl ins> 

^ ^ 3, 


3^ -i, Q*^*l **4 ChecI for vsrisble with no rsonzero mstruj coef *f icierit > 

select ivar^vsT-id fron. iv^sr where 1 vsr* vsr—id '" = 
select iniat.vsr.-id from imst where imet . n>et_el emcrit “= 0 ' 
3f -f Qt3.r ..4 Checi' for co^is t rsxnis: hsvir»s' nc nonzero LNS elements but 

With nDnrero RHS Uslues > 

select icor* ♦ coris_id r cons-.t ype f rhsvalue front icorificonsd 

where icori.cons~id“icorisd.cons_ad end rhsvslue C 

end iconsd. cor.s-id ''= 

selfecl 3 nist ♦ coris^id from imst 

where imet . ni5t-.el emerti C snd in.st .cons-id 


Fig. 12! Queries for Simple Error Checking. 


/ 
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(mat_element) is not zero. Then the outer query selects the 
variable identifiers (var__id) from input relation var__list 
(ivar) "which are not contained (if any) in the list of vari- 
ables obtained from the inner query. Thus the entire query 
block is able to check for a variable with no nonzero matrix 
coefficient. 

In the second query (Cls3.2) the inner query block 
obtains from input relation matrix (imat) all those constraint 
identifiers (imat. cons_id) other than objective function, and 
for which the coefficient value (s) (mat_element) is (are) not 
equal to zero. Then the outer query block selects from input 
relations cons_list and cons__detail only those constraint 
identifiers which are not in the set of constraint identifiers 
obtained as the result of inner query block. Thus the inner 
query block selects all constraints other than objective func- 
tion which havr coefficients for left-hand- side and then 

chocks for non-match with constraint identifiers (cons_id) of 
relation cons__detail having right-hand- side value (rhs veilue) 
other than zero. In the above manner the query provides simple 
error check for constraints having no nonzero LHS elements but 
with non- zero RHS value. 

Thus Figure 12 provides sample queries representing 
"Simple error checking" features associated with a linear program. 
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(iv) Sophisticated Checking s 

Many of the LP packages provide for a picture clause 
which pictures (displays) elements in a range say (100-999). 

One can easily get such pictures using SQL, Problem specific 
data checking like the set of variables that use specific 
resource say "WATER." (in our example agricultural planning 
model), can be obtained. This kind of checking may be quite 
significant for model validation as a quick check. Relatively 
easier checks for simple upper bounds, generalized upper bounds 
can also be made. Pattern matching, say checking for a 
'transportation" type constraint set, can also be obtained. 
Sam.p2e query (Qe4) in Figure 13 illustrates these features, 

The first query (Qi4.l) obtains all fields of input 
relation matrix (imat) for which the coefficient values Cmat_ 
element) lie between 100 and 999 and displays the result in 
ascending order of fields (var_id) and (cons_id) of relation 
matrix (imat). 

In the second query (Qs4.2) the "select" verb obtains 
variable identifiers (var_id) uniquely from input relations 
matrix (imat) and cons_name_list (iconsn) lor which constraint 
identifiers are same and constraint nejne (cons_name) is having 
a match either with string "WATER*" or with string ’H/ATER*". 
Thus the above query is able to obtain the list of variables 
that use a specific resource, say "WATER" in this case. 



>> NOTE : Line^ stsrtins with 'n' sre 'Comment' line 
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^ ••• So'-"'hisi icc'ted cheoMnsi > 

^ jr ^ 

■{. QI^*1 * * * PictuTAFiSi the fiiotri; in £■ rsr»se y 
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order by imet*ver_-id esc ♦ imct * consul d esc/ 

% -C 0:-c.2 Oeriehles that use e specific resource -* ssy WATER > 

select uniGue imat , vst _id y cons»nsme fron. imet y iconsri 
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3| < U*A^? Simr-ic Up;-er Round > 

select icorjsrj*cor»s_3 df cons-nsnie from iconsn^insl 
where i n*: i ♦cons-.a d-a corisfi* cor)S_i d srid a corjsr, , cons_i d 
select in.el •CDriE_id from anist where a met * mallei ement 1* 
£TDu: bv 1 ccTisn* coris-id 

l.rvafi' ri.i ’ in-e I *n.ci_elen'er.t ' -3 


3J ' r , ^ , fv- . e T j , 2 *. d U' per r ou-id > 

select ieori^rj*cons_ia* coriS-nsme fron. iconsri • ime 1 
where inict ♦coris„id=icon£n4ConE_io and a cor-sr. , c orrs _a o 
select a met ♦ cofjs-id from amet where imst • mat_elen ent "= 1? 
STOUF t'S iconsri ♦ cOFiS-id 
hevan^ sum ( imsl •met-^elenienl ) 1/ 

-C QIA*Z *»* Trerisport 51 or ty'^e FCttern > 

sole:! imsl * var-adr count from iftiat 

where imet - met_elerTier<t=l and mat ♦ cons_id"= ' 1 ' 

STOJF by iFf.at ♦ v'ar -id / 

seltcl imeUcons-adf cour,t<3j^) fron. in.at 
wherp imat ♦ n.at-c Icn.cnt”! end in.ot ^ cons-id"- ' 1 
CrouF b-* a me 1 + cons -ad ' 


Fig. 13s Queries for Sophisticated Checking 
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In the third query (Q»4.3) the inner query block obtains 
the matrix (imat) constraint identifiers (cons_id) for which the 
coefficient value (mat__element) is not unity. Then the outer 
query block selects only those constraint identifiers and 
associated constraint names from the join of input relations 
cons_name_list (iconsn) and matrix (imat) which do not match 
with the results of inner query and finally displays after 
grouping them according to constraint identifier for v/hich the 
coefficient value (mat__element) sum is equal to unity only. 

Thus the above quehy detects the simple upper boimd situation. 

Similarly, in the fourth query, (Qi4.4) the inner query 
block obtains those matrix (imat) constraint identifiers (cons_id) 
for v/hich the coefficient value (mat__element) is not unity. Then 
the outer query block selects only those constraint identifiers 
and associated constraint names from the join of input relations 
cons_name__list (iconsn) and matrix (imat), which donot match 
with the results of inner query and finally displays after 
grouping them according to constraint identifier for which the 
coefficient value (mat_element) sum. is greater than unity. Thus 
the above query is able to display the generalized upper bound 
situation. 

In the last sc't of two queries (Q^4.5) the first query 
obtains from input relation matrix (imat) all those 
variable identifiers ( var_id ) for which 



124 


the coefficient value (mat__element) is equal to uiiity and 
constraint identifier (cons_id) is other than for obdective 
function. Then after grouping according to variable identifier, 
displays the variable identifier alongwith total number of 
such occurrences in that group. The second query obtains all 
those matrix constraint identifiers (imat.cons_id) for which 
the coefficient value (mat_^element) is equal to unity and 
constraint identifier (cons_id) is other than for objective 
function. Then after grouping according to constraint identi- 
fier, displays the constraint identifier along v;ith total num- 
ber of such occurrences in that group. In this way above 
query can detect "transportation" type pattern. 

Thus Figure 13 provides sample queries representing 
"sophisticated chucking" features associated with a linear pro- 
gram. 

6.2.3 Output Analysis 

The analyst/modeller would not stop at model construction 
and input data analysis. He may generally prefer to go for 
solution values and further related analysis based on the 
solution obtained from the problem solver. In particular, 
he may like to have solution analysis or some kind of sophis- 
ticated analysis. 

(i) Solution Analysis » 

The modellcr/analyst may be interested in some simple 
report or partial summary related to solution values e.g.. 
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printing of solution values in a specified order, partial 
summary like breakup of profit into broad catagories, print- 
ing of constraints in a specified order, say decreasing order 
of shadow prices. Sample query (Qi5) in Figure 14 illustrates 
these features. 

The first query (0^5. l) obtains the output variable 
identifiers and associated solution values from output relation 
var_value (ovar) for which the solution value is greater than 
zero and finally displays the result in descending order of 
solution values. 

In the second query (Qi5.2) the first query block 
obtains the profit contribution from atoms of the "ORCHARD " 
molecule- using aggregate function "sum". This is achieved 
by selecting the solution value from output relation var__value 
(ovar) and profit coefficient value from input relation matrix 
(imat) corresponding to same variable identifier and taking 
product of the two values. The products are added together 
using aggregate function "sum ". Similarly second query block 
obtains the profit contribution coming from the field (i.e., 
"FIELD") molecule atoms (i.e., "COTTON", "ONION"). Thus the 
query displays the profit, contribution from the specified 
type of crops in the current solution. 

Thus Figure 14 illustrates queries representing "Solu- 
tion analysis" features associated with a linear program. 
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»» NOTE : Linci. stertins with 't' ere 'CoRiirterjt ^ lines,* 


$ -C GJE Solution Anslysie > 

, ^ j 

< Q:S*1 ♦** Sin'^le R‘o'-ort > 


oclfccl OV ST ♦ V£T-_3 d y OV e t * SdIuI lOfi f T on. Q\ST 

where ov s’- -sclutiori " 0 

order bs: ovsr*solutior» desc / 

< Q:r*r *** Psrtiej S’jnm.ery ^ Contribution fron^ Orchard and Field > 

select ctjni<iR»at 4 n.at_elenient:^DvaT *sclutiori^ f ron. iniatyovsr 
where intsi * Vor.«i c'-ovsr ♦v-'s r_i d and iniat * cons_id- 1 

and Dva'^* var-id is in ' Af PLE^^c ' y ' ORAK’GE’f ' / 
seleci £ur ( aix^et 4 nist>elen,ent ^ovai *£clution> f ron in,sx rover 
w?iere met * vs r-.id-Gvar 4 vsr ^id end i n.st , cone^ i o= ' 1 

ci.-J o.ei.VcT^ad as ir ^ CCTTOr'* ' ^ ' 0 ? ‘J 0 f-'> ' / 

5 ! f '-Di in.: I where ir4,£ i , cor a : = '2 

stleti ^ fror. over / 






Fig. l4i Queries for Solution Analysis 
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(ii) Sophisticoted Analysis » 

Ihe analyst may like to hav^ specialized reports such 
as list of variable identifiers in increasing order of profit 
contribution and the list of binding constraints adong v/ith 
the right-hand" side vc^lue for each of such constraint identi- 
fiers. Sample query (Q.6) illustrates these features in 
Figure 15. 

The first query (Qs6.l) displays the product of coeffi- 
cient value corresponding to objective function constraint 
identifier and a variable identifier from input relation 
matrix (imat) and "solution" value corresponding to some 
variable identifier from output relation var__vaiue (ovar) 
for which the solution value is greater than zero only. The 
result is displayed in default (ascending) order of the 
product value. 

The second query (Q;6.2) selects those constraint 
identifiers for which slack value is zero. This is done by 
joining the relation (ocon) and (iconsd) using constant identi- 
fier (cons_id). In the display the constant identifier 
and rhs value are shown. 

This Figure 15 illustraues queries representing "sophisti- 
cated analysis " features associated with a linear program. 



NOTE t Lines stertiris with are ^Comrnerit ' lines 


-C Q:6 *♦. Sc'F J'lisl j rated Analysis > 

> 

< Q:6*3 • . -» VancL. 36 List irt increasiris order of srofit coni ribut i or. 

sele^ct in.st.n.c'l«.el6mentJ»^Dver*solut lOTi f ron. inist rover 
whore in.s L * v 3 r„id=oveT ♦ va^-i d and inist *coriS_id=^ ' 1 
end ovar , solut 1 on 0 / 

< Olt^r * * . I-iridi fiS const Tair>t with RHS values > 

>jclect ocoFt* cons -idr iconsd » rhs val uo 
•frcn occur icor.sd 

wht. rf^ Dcort , cons-id = iconsd . co^.s_i c 
and ccori*siacl ” 0? 
t'T jor hv ocLF. cor.L~:s desi 




Fig. 15s 


Queries for Sophisticated Analysis 
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6.2.4 " V'/hat-if " Analysis s 

Once the solution for the problem is known, the analyst/ 
modeller is further interested to go for several "what-if 
analyses related to problem domain. The major ones are fea- 
sibility check, routine sensitivity analysis, 100^ rule, 
simple analysis, revised solution with some perturbation, 
relative ratio of contribution and effect of tightening /relax- 
ing an inequality. Sample query Q%7 illustrates these features 
in Figure 16. Each one of them is discussed below. 

(a) Feasibility Check s 

In an LP model any initial solution is of much signi- 
ficance to start with. A modeller may be interested in fea- 
sibility check of a specified solution or a perturbed solution, 
i.e., he may be interested to check feasibility if some vari- 
ables are increased by certain percentage while some other 
variables are decreased by a certain percentage. This kind of 
feasibility check can also be made. The query (Q»7.l) illus- 
trates this feature in Figure 16. 

The query (Qs7.l) displays for each constraiuit identi- 
fier the detailed information viz. constraint identifier, sm 
of the product of coefficient value and associated variable 
solution value, the constraint type and right-hand- side value 
from relations cons___detail , matrix and var__value. In this 
process care is taken to ensure that constraint identifier 



NOTE 
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ere ^Comment' lines 


■C C 7 

< 0 : 7.1 


< q:?.? 


< 0 : 7.7 
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. Uhst If Ariolysis > 

Feasibility Chet'}' > 

t,elfrc t lcoiiEd.cor.5,_id.suii,<iii,tl .n,et_e J rn,e:T>tJlov6 r . sol ut 1 on r 
corj«:-.tyre* rhsvalue froni iconsd? iitial ? ovsr 
where icoriso.cons^id = iniat . cons-.id and over* var -„id~ 
intal ♦verbid and ift>3l . consul cJ ''1 ' 

MOUF by in»ai.cDris-.id'' 

... Tvoui 2 ne Sensitivity Arialvsis J Output in sortie oroer > 

select sufr»(ovBr*solutiorf3»^currerft«.cost ) froni ovsrrobur 
where over .v'ar-id-otijir ♦ vai _id ar»Q over .solution 0 
select ova i .vaT-idfCv'ar.solutior.yOvar * solut ior»3l cur rerit„C'os i 


i 1 OTu ovar-obur 


where ovaT.vsr-.id = obur.vsr-id 

crdcT by cut rent.cost desc ' 

... 300“. f'ulB : Siniul tsrieous Chsnses withir» Ranses > 

fTacble objective coefficients chsnse bt 23. > 

df 1 e te of ura'i ' 

Imes 0 

I e c t obuT ♦ var _ id> ob jr . vst _ id y cur t ent-cost y cos t_ ir»c reas e ♦ 
CDS 1 -dec T ease ^current -Cl stJ^l .02 f:oi. cfc-ui 

2 r.tc- fl/ 

iriic of *jr«r t ' ! of u”. > c vl f o-^ 1 • * of 3 > cf A ' : 

f T t«n fl ' 

u-ufl- ofuricl St-l c *'b“ :c‘r--cf 1 1 ' cf 2 where C 

utdBit ufunct set of 2*= (of A-of 1 )/of 2 where iDf4“ofl' 0 / 

sclfvi >} from ofurict/ 

select sun. (of 5) f i on ofurjcl»ovar 

where }■ of uri= ovar.var-id / 

... Siiuplc Arit^lysis 7 

c voTiClle sas £ create hPS file > 

1 3 nes 0 
srparator ' ^ 

select corjS-typE y iconsd.cons-id from icortso into w2/ 

Ijncs 0 
se’"-aTator ' 

select imat ♦ var-i d ♦ imat . con = -id y 1 iT.st * mst-elenjent f rori* mat 

where 1 H'ot . va T — 1 d ^Q{\10t*^ into w4/ 


line£ 0 

c c F c r ator ^ ^ , 

sc'lc'cl 3 ronsd . couc - 1 Ci • rhi V a 1 ue froir. iconso into wo/ 


Fig. 16 


Qu6ri6s for An 0 . 1 ysis> (ConLci.) 
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NOTE : LiriM. sisrtirjS with are ' Cotnmerit ' lines. 


■X Qt7.5 Revised Solution with some perturbstiori > 

delete ofunct/ 
lines 0 

sol ec t over • ver -1 d * ovar * vsT^idrO'.er.solution^relati ve^cosl 
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'CDTT0N3I ^ f 'ONION)* / 

update ofunct set of -4=of 1* 1 ♦ 02 where not kofun is ifi 
'COTTON* 'ONION)* ' / 
select * f T on, ofunct^ 

sei e^c I 1 cor. so 4 cons-.id * suni( imet . nisl-elGnient*of 4 ) y 

corjs>,lyp e f rhsv o 2 ue from i consd ? imat • o ver r o’^'unct 
wht'Te ironsd. cons « id- iniot . corts_ id end c^'ar. ver»io=intat . vs: _ in 
arid of ur. - in.et.vsT^id srid i mat . con£«.id * 1 
sreup bs 1 met* cons 1 d '' 

C ... Relative retaO of cofit rib»ut ion f ron« cross and livesxDcl- 

ss furtctiori c>f cost vector > 

-C ril Be sir vcTicble objective coefficierls chsnse bs 2/- > 


c:7.7 


delete’ ofurici/ 
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' 'Tt^sull)*' y 'result* 'yC.OyC.O -0. Or 0.0 yC.C / 

uj^'dcie ofunct set ofC= 
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utitTCr I'Ctu'' = 'reeuit* ^ 
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i^ofun IS in 'CCTTOK* ' ^ 'ONION* ' 5 

wbiere ko-fun= 'result*'/ 
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ueocte otunct set of2== ^ 
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net ^ofun IS in 'COTTON* ' r ' ONION* ‘ ? 

where f of un ^ 'result*'/ v"* 


result*' arid 


The 
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> 
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Fir. 16: Queries for Analysis 
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does not belong to objective function^ solution values are 
greater than zero,* constraint identifiers of relation, 
'-cons_detail " and ''matrix" match and variable identifiers 
of relations "matrix" and "var_value" also match. Thus 
from the display the user can check for the validation/ viola- 
tion of feasibility of solution values. 

(b ) Routine Sensitivity Analysis '-. 

The modeller may be interested in some kind of sensi- 
tivity analysis done on routine basis viz. displaying 
output in some order. The query (Q^7.2) illustrates this 
feature in Figure 16. 

In the sample query ( Q i 7.2 ) the first block 
obtains sum of the product of variable "solution" value and 
associated current_cost from relation "var_vaiue" and 
'"cost__range This is conditioned by the following variable 
identifiers of relations "var_value " and " cost_ranga’' should 
match, and variable " solution" value is greater than zero. 

The second block of query then selects variable identifiers 
corresponding to var_value, "solution" value and product of 
"solution" value and current__co st from relations var__value 
and cost__rangc. In the process care is taken to ensure that 

variable identifiers of relations var_value and cost rcange 

match. Finally, the result is displayed in descending order 


of current cost. 
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(c) 100 % Rule ; 

All the range analysis traditionally is based on 
single change in either objective function coefficient or 
right— htind— side (RHS) value. However, for sii.iultaneous 
change within range in more than one value of either objec- 
tive function coefficient or right-hand- side (RHS) value 
"100-^ Rule" [31] can be tested. The query (Qi7.3) illustrates 
this feature in Figure 16. 

The sample query (Q5 7.3) checks the "100 percent Rule" 
for 2 % increase in basic variables values. In order to test 
this rule the query block deletes the output relation "ofunct" 
and then initializes the fields of "ofunct" and it sets field 
"of5"of relation "ofunct" equal to absolute proportion of 
contribution from each updated variable. The next query dis- 
plays fields of relation "ofunct". Further query block 
obtains the value of summation for all records for which 
the "ofunct" key matches with variable identifier of relation 
var__list. 

(d) Simple Analysis ^ 

A modoller/analyst may like to add or delate one or 
more variable (s) and sometimes prefer to add/delete one or 
more constraint (s). Sample query (Q57.4) illustrates one 

such situation in Figure 16. Simple analysis such as delete 

\ 

a particular variable i.e., "ONION" (e.g.. 


a variable n 
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in the agricultural planning problem described in Sec. 4.4.1) 
from the model formulation. 

In the query ( Q 1 7.4 ) the first block obtains 
constraint type (cons_type) and constraint identifier (cons_id) 
information from input relation cons__detail (iconsd) for 
"ROWS" section and stores in file "w2" . Then the second 
block obtains variable identifier (var__id), constraint iden- 
tifier (cons__id) and coefficient value (mat__element) from 
relation matrix (imat) for which variable identifier (var_id) 
donot match with "ONION*'' for "COLUMNS" section and stores the 
result in file '■w4 " . Next the third block obtains the 
constr'-'int identifier (cons_id) and right-hand- side (rhs value) 
information from relation cons__detail (iconsd) and stores the 
result in file "w6 " • Then finally all these axrcernal files 
along with some formatting files are concatenated and processed 
by interface programs to generate anl/IPS file for model formu- 
lation without the variable "ONION ". Similarly other simple 
analysis as mentioned for other situations can also be made. 

(e) Revised Solution with Some Perturbation s 

A modeller/ analyst may like to analyze the solution 
after some perturbation done by him in some group of variable 
values. For example, with reference to sample problem 
described in Sec. 4.4.1 he may like to decrease the value, 
say by 3 percent for "FIELD" crops (i.e.. 


"COTTON" or "ONION") 
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and increase "the value, say by 2 percent for rest of the 
variables and then check lor the feasibility associated 
with present value of variables. Sample query (Qi7.5) illus- 
trates above aspect in Figure 16. 

In the query (Qs7.5) the first block initia3.izes the 
relation "ofunct" by deleting all its previous records. Then 
next block obtains field values from relation var__value and 
stores the result in file "f2" which is then used to insert 
information in relation "ofunct" using next block of qucr^^. 

Then a query block updates the field "ofunct.of4 " content by 
0.97 times for those records having key match with "COTTON*" 
or "ONION*''. Similarly another query bl(^ck updates "ofunct.of 4" 
content by 1.02 times for those records having no key match 
with "COTTON* "and "ONION*". The next query block simply 
displays the updated information. Finally the last query 
block displays constraint identifier, computed sum of product 
of coefficient values and associated updated solution values, 
constraint t 3 ^e and right-hand- side value for each constraint 
identifier as described in feasibility check (0^7.1). In the 
above manner, the "what- if" analysis of this kind can be 
made. 

(f) Perturbation Study of a Function of the Problem s 

A modeller/analyst sometimes may be interested in 
sensitivity of an • object-ive function which is 
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derived from the problem structure say a function 
of some right-hand" side values. For example, he may be 
interested in the ratio of overall profit from a group of 
variables to overall profit from another group of variables 
as a function of some data. With reference to example prob- 
lem described in section 4,4.1, he may like to increase the 
objective function coefficient values for variables, say by 
2 percent and then like to obtain the ratio of profit contri- 
bution from "FIELD " crop (i.e,, "COTTON*"or "ONION*'' ) to 
overall profit and ratio of profit contribution from rest of 
the variables to overall profit. The sample query (Qt7.6) 
illustrates the above aspect in Figure 16. 

The query (Q«7.6) accomplishes above task usizig several 
blocks of queries in sequence. The first block initializes 
the relation "ofunct" by deleting all its previous records. 
Then sc-cond block of query inserts field values for "ofunct" 
relation by obtaining the required field information from 
relation cost__range (objr). The third query block updates 
field "ofunct. of4" by selecting information from relation 
var__value corresponding to matching variable identifiers. 

Then the fourth query block updates field "ofunct, of 5" by 
setting the value equal to 1,02 times of the product of coeffi- 
cient value and associated solution value. Next the fifth 
block of query inserts a record with "result* " as its key with 
all other field value initialized. 
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Then the sixth query block initializes the field 
"ofunct.of5" by obtaining the sum of the field (ofunct.of4) 
values for which the key donot match with '‘result* "» Next 
the seventh query block updates the field (ofunct.ofl) by 
obtaining the sum of profit contribution for variable identi- 
fier that match with "COTTON*" or "ONION* ", corresponding 
to record with "result*" as key. The eighih query block 
similarly updates the field (ofunct.of2) by obtaining the sum 
of profit contribution for variable identifiers thet donot 
match with "COTTON* "or "ONION*", corresponding to record 
with "result'^' " as key. Finally, the last query block dis- 
plays tho profit contribution from field crops, profit contri- 
bution from rest of the vftriables, overall profit, ratio of 
field crop contribution to overall profit, ratio of rest of 
variable contribution to overall profit. 

Thus tho above query (Q«7*6) in Figure 16 provide the 
information of relative ratio of profit contribution to over- 
all profit contribution. 

(g) Tightening or Relaxing an Inequality a 

The modeller sometimes may like to tighten or relax 
one or more inequality constraint(s) due to restrictions or 
changes in availability of some specific resource. He may 
like to have analysis of the model solution in light of 
recent or likely changes. Sample query (Q»7.7) illustrates 
this aspect in Figure 16. 
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In the query (Q»7.7) the first query displays all 
fields of relation cons_detaii (iconsn). The next query 
block updates all ''cons__type" of relation cons__detail (iconsd) 
to equality ( E ) i,e., tightens the constraint inequality 
corresponding to specific constraint identifiers (e.g., ”5*", 
" 6 *", "7*" ). The last query again displays the fields of 
relation cons_detail to illustrate the modification done. 

Thus all the sample queries illustrated in Figure 16 
provide a wide range of "what- if " analysis a modeller can have 
for a linear programming model. 

E'urther, all the queries together demonstrate the 
various data management capabilities of LAMP using the rela- 
tional format as proposed in our thesis. 

The queries cited above are purely indicative of the 
capabilities of SQL like data manipulation languages and by 
no means exhaustive. The richness of the queries that can 
be constructed are only limited to the modeller's innovative 
capabilities. The queries are not limited to SQL language 
alone. Many of the relational database management system 
do support an SQL like language with minor syntactic diffe- 
rences. The ideas illustrated do apply to a more general 
situation as well. This way we are able to take advantage 
of the well developed theory of relational databases without 
we having to write a separate data manipulation language. 
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CHAPTER VII 

SUMMARY,, CONCLUSIONS AND RECOMMENDATIONS 

7.1 SUMMARY OF WORKS 

Our modelling system LAMP accomplishes to a large 
extent, the objectives we had set out for ourselves in 
Chapter III. LAMP provides an environment in which an 
optimization modeller can describe the model structure, 
obtain the solution of the model, view the results, write 
reports, perform sensitivity analysis, change parameters 
and re-solve the problem. Almost all these tasks can be 
accomplished in an interactive manner using a medium vfhich 
is natural to the environment. The implementation is 
achieved using a model specification language to represent 
the structure and a model manipulation language to manipu- 
late the structure and the data. The model specification 
language is specially designed as part of this thesis, while 
the model manipulation is accomplished using a standard 
query language. To enable the use of a query language, an 
interface between the problem processor and the mndel lan- 
guage is also developed in this thesis. Such an interface 
also introduces an attractive independence between problem 
processor and modelling languages. In short an integrated 
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system to support an optimization modeller in all the phases 
of the modelling life cycle has been developed. 

7.2 CONTRIBUTIONS s 

The major contributions of this thesis, in our opinion 
are as follows s 

(a) Demonstrating the feasibility of an integrated system 
to support optimization modelling 

(b) Development of a modelling language which is simple 

to learn, powerful eno\igh to model a variety of situations 
. and yet keep close resemblance to the natural v/ay in which 
.c. modellers perceive the model. 

(c) Outline a possible interface structure between problem 
processors and modelling languages permitting one "fco 
exploit the combined advantages of independent aevelop- 
ments in these areas. 

(d) Exploit the powerful capabilities of relational 
algebraic query languages to permit a variety of 
’'what-if analysis to be performed. 

« 

7.3 LIMITATlONSs 

Since our primary aim was to prove the ideas, our 
implementation is far from perfect. We have not included 
efficiency considers-tions in the implementation, which we 
plan to look into in the near future. Also we have limited 
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ourselves to optimization modelling, even though we woiold 
very much like to enhance the scope to several other related 
techniques as well. Since, even the extension to general 
nonlinear programming situation is not very simple, exten- 
sion to capture other modelling situations does appear to 
be reasonably hard. 

7.4 RECOMMENDATIONS FOR FURTHER WORKI 

Any work of this nature in this area is bound to open 
up several new ideas that can be taken up for further work. 
Specifically we feel that the following ones are the most 
promising ones, with a likelihood of significantly changing 
the modelling scenarios 

(a) Extension to general modelling situations as has 
been recently proposed by Geoff rion [76] 

(b) Providing explanation capability to the model systems 
in the line of recent work by Greenberg [83] 

(c) Use of pattern recognition techniques to create a 
family of Intelligent Modelling Systems. 

(d) Use of Program Generators to assist the task of the 
design of modelling languages. 
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APPENDIX A 


FURTHER EXAMPLES 

FOUNDRY CHARGING PROBLEMS [l3l]: 

A foundry can use four different kinds of scrap 
alloys of various composition as raw materials to produce a 
special casting, wbich will be called here, "cast-A". 

Table A-1 and Table A-2 summarize the chemical compound, the 
cost of raw materials including the melting cost, and the 
chemical compositions of cast-A to be produced. 

Table A-i; Chemical Compound and Cost of Raw Materials, 


Raw Material 

Chemical Compound in Percent 
Aluminium silicon Carbon 

Cost/ 
unit wt 

Alloy-1 

5.0 

3.0 

4,0 

50.0 

Alloy- 2 

7.0 

6.0 

5.0 

70.0 

Alloy~3 

2,0 

1.0 

3.0 

60.0 

Alloy-4 

1.0 

2.0 

1.0 

40.0 


Table A-2i Chemical Specification of Cast-A to be produced. 


Chemical 

Compound 

Atleast 
in percent 

Atmost 
in percent 

Aluminium 

3.0 

6.0 

Silicon 

2.0 

4.5 

Carbon 

3.0 

6.0 


• The foundry has a limited supply of Alloy-2 at a level 
of 400 units and of Alloy-4 at a level of 200 units. The 
management of the foundry wishes to determine vvhich alloys 
in what quantities (units) should be included in a 1000 
units charge so that they can minimize the raw material 
cost for producing "Cast-ii". The different raw materials 
availability and total charge required are summarized in 
Table A-3 below. 

Table Ar-3 . Raw Material Availability and Total Charge 
in Units. 


Alloy-1 


Alloy- 2 

400.0 

Alloy- 3 

- 

Alloy-4 

200.0 


Total charge for 

"Cast- A'' 1000.0 


The LAMP formulation for the above "Foundry Charging 
Problem"is given in Figure A.l and Figure A.2'. 

GASOLINE BLENDING PROBLEM [ 131] s 

An oil company produces three types of crude oil 
components — components 1, 2 and 3 ” with the specifications 
shown in Table A-4 below. 



y !t note ; Lines, »t.rtina with ,re 'Com».er.t' linec. 

» TERMINOLOGY PHASE 

» MOLECULE 

RAWMAT=AL1 » ALOt AL3rAL4 
COMrOUNr'---AL rSl »c 

RAUFOUNIi- ALO.ALA 

* I rn N’T 3 TIER 

* RAUMATERIAL COST : 

COST .RAUMATt 

i» coMrosnioN eactor ; 

COM' ■OLi , f'AL''',A'r . rD>'''OUHriS 

* M’NIMUr RLtnURLHCNT.* 

ATLCAST .CDh( OUNM! 

* MAXIMUM RTOUIREMENT T 

ATMOST .COMF OUNIi* 

* TOTALCHARBE OF MELTING : 

TOTMELTl 

* BOUNHS ; 

CEILING. RAWIiOUNIH 


( Table A-1 ) 


( Table A-1 ) 


( Tabic A-2 > 


( Table A-2 ) 


( Table A-3 ) 


( Table A-3 ) 


Fig. A.l: "Fomdry Problem"’ Terminology Phase 


}| ! > NOTE X tines starting with 't' are ''Corwiient' lines* 

jg: s sc * at = ~ * » = * « “ « ® = » * * *= w « “ = s: = r s s ss r: s: as as B X sr a ss » ss s= 5s at s: ai ns ss *s s: ss » c as s: XT le c 

t PROBLEH STRUCTURE 

$ OBJECTIVE 

HINCRAWHAT : COST * RAUMATtRAWMAT'5‘3 

* CONSTRAINTS 

$ Miniojuffi Constituent Reeuirement 

SUM £ RAWM AT X COMPOSE * RAWMAT * COMPOUNH*RAWMAT^I =^ATLEAST * COMPOUND 
t Totalnielt Reauirenient 

SUHl RAWMAT :RAWHAT?3 == TOTMELT 
3^ He; loiun Coristituent Recsui Ten.ent 

SUMt RAUMAT ; COMF'OSE . RAWMAT . COMPOUNTORAUMAT'^3 = ATMDST . COMPOUND 
II Ceiling on Rawniatensl 

RAUgOUND ? CEILING *RAWBOUNIi 


31 :==.=: 


Fif. A. 2 


"Foimdry Problem" Model Structure 



Table A-4i Crude Oil Component Specifications. 


Component 

Performance ' 
(Octane No) 

'Vapour Pressure 
(lb/inch2) 

Production 

(Units/day) 

1 

110,0 

10.5 

40.0 

2 

100.0 

5.0 

60.0 

3 

90.0 

12.0 

80.0 


The company blends these components to obtain 
gasoline-A and gasoline-B with following specifications s 

1. '-^'he minimum acceptable performance number of gasoline-A 
is 90 and of gasoline~B is 100, The performance number of 
each kind of gasoline is estimated by the weighted average 

of the performance numbers of the component blended. 

2. The maximum acceptable vapour pressure of gasoline-A is 
12 Ib/inch^ and of gasoline-B is 7 Ib/inch^. 

The vapour pressure of each kind of gasoline is esti- 
mated by the weighted average of the vapour pressures of the 
component blended. 

How should the company blend the three components to 
produce gasoline A and gasoline B such that total daily 
profit is maximized. Components 1,2 and 3 are produced at 
the required levels of 40, 60 and 80 units per day respectively 
so that the corresponding requirement constraints are binding 
constraints with no slack. At present gasoline A sells at a 
profit of 5 per unit and B at 8 per unit. 



vrasoline features required are summarized in Table A-5 


below. 


Table A-54 Gasoline Features Requirement. 


Type 

Unit 

Profit 

Performance Number 
(minimum) 

Vapour Pressure 
(maximum) 

lb/ inch2 

A 

5.0 

90.0 

12.0 

B 

8.0 

100.0 

7.0 


T?ie LAMP formulation for the above Gasoline Blending 
Problem is given in Figure A. 3 and Figure A, 4, 

PRODUCT-MIX PROBLEM IN A BAKERY [ 131 ] 5 

Delight Bread and Bun Co. (DBB) employs two parallel 
baking lines, one for bread products and one for buin products. 
Each line is independent of the other, although most of the 
baking operations with in the facility are similar in nature. 
The study was initiated by the management with the objective 
of determining the amount of each of three types of bread 
(1.5 lb. white bicad, 1,5 lb. wheat bread, and 1.0 lb. white 
bread) and two types of buns (hamburger and hot dog buns) to 
bo produced in order to maximize the profit. Both of these 
products are subject to constraints imposed by the capacities 
of individual machines in the production lines and the consu- 
mer demand for the products . Based on the forecast information 


» >• NOTE : Lines starting with 'Co».«.ent' lines. 

t TERMINOLOGY PHASE = 

^ MOLECULE 

CRUr»ETYPE=^ly2f3 
GASOLINE=ArB 
GASA=A1 f A2»A3 
GASB=B1 fB2fB2 
CRUU1=A1»B1 
CRUP2=A2*B2 
CRUri3 = A3rB3 

* IDENTIFIER 

t UNIT PROFIT : ( Table A-G > 

PROFIT. GASA$ 

PROFIT.GASB$ 

t PERFORMANCE FACTOR : ( Table A~4 ) 

FERFFACT.GASAS / . 

PERFFACT.GASP^ 

Pe rf orn.3r«c e Number Required : (Table A-5 > 

OKA« 

ORB 5 

3^ UoFOur y-Tessy^'e Esc Lot < 7 able f-< > 

VPFACT.GASAf 

VPF ACT .GASB^ 

t HaMmum Uay-our Pressure ( Table A-5 ) 

MAVPGASAi 

MAVPGASBi 

* Daily Production ( Table A-4 ) 

DPRODLl^ 

DPR0DL24 

OPRODLSS 

3| Perf orrtisnce Factor Balarice 

BPFGASAi 

BPFGASB:^ 

* U 3 FOUT pressure balance 
BUPGASAf 

BUPGASPf 

3l Unit Factor 

UNITFACT .GAGAf 
UNITFAC7 .GASD3 


Fip. A. 3: "Gasoline Blending" 


Terminologj'- Phase 


•' NOTE : Lines startins with «re 'ComH-ent' lines 


$ 

t F-ROBLEH STRUCTURE 

* OBJECTIME 

HAXC6ASA;PR0FIT*GASA*GASA'?3 + rGASB ^PROFIT , GASB:|iGASB^3 

* CONSTRAINTS 

3^ Ociarie Number Reauaremeiit for Gesolirie-A 

SUM C GAS A J F'ERTF ACT # GASAJ^GASA'^D + ALPHAEGASAIUNITFACT .GASA3f5ASA'''3 'BFFGASA 

* Octal le Nuniber ReQuirement for Gasoline-E 

SUMCGASB: PERFFACT *GASB2*JGASP'?3+ALPHAEGASB:UNITFACT ^GASBJ^BASB^f^T ==BPFGASB 

t Var-our Pressure Reoui renient for Gasoline~A 

SUMEGASAIVPFACT . GASA)^GASA'T^3+ALPHACGASA:UNI TRACT* GASA*GhSA'?3 =^bupgasa 

* VcHour r res sure Rec?uirement for Gasolirte-B 

SUMIGAEI ;UF'r ACT , GASP)* GASB'^ 24 ALF‘HAEGASB:UNITFACT ,CA3B3f G^SI "O =BUPQASI 
^ Iirilv production of Crudl 

suMCCRura :cRUBi'?3 == bproi/li 

* Bails production of CrudC 
SUMrCRUIi2:CRUH2'f2 = DPR0rtL2 

* Baily production of Crud3 
SUM ECRUB3; GRUBS'? 3 = BPRCDL3 


Fig- A. 4 


"Gasoline Blending" Model Structure 



the estimated weekly bread and bun demand are as follows s 
White bread (1,5) ’'; 

Thi.s is a stable product whose minimum should be greater 
than or equal to 280000 loaves per week. Maximum should be 
limited to 300000 loaves per week. 

Vdieat Bread (1,3 Ib) ^ 

IJheat bread is not as popular as white bread and is 
produced mainly to demonstrate a complete bread product line. 

A maximum production rate of 120000 loaves per week is consi- 
dore<i to be realistic. 

White Bread (l.O lb) ? 

This smaller loaf of white bread is not as popular 
as the larger loaf (1.5 lb) and hence the maximum demand is 
expected to be at a level of 40000 loaves per week. 

Hot Dog Buns * 

The maximum demand constraint is 33000 packages per 
week, the. minimum demand is 15000 packages per week. 

Hamburger Buns '^ 

The maximum output constraint is 80000 packs p^r week, 
the minimum output is restricted to 20000 packs per week. 

The yearly profit on sales figure are shown in Table i^6. 



Table 4-6 • Yearly Profit on Sales. 


Product 

Profit 
Cent per product 

Dollars per 
10000 nroduct 

l.b lb, white bread 

5 

500 

l.b ]b. wheat bread 

4.5 

450 

1 lb. v/hite bread 

5.5 

350 

iiot dog buns 

5 

400 

Hamburger Buns 

4 

400 


Thfi first group of operations performed in the pro- 
duction of bread (blending, dough formulation, mixing and 
fermentation) are best grouped together as one operation 
because of their inter-relationships and because their 
capacities arc difficult to Isolate. Thus, all processes 
performed by these machines will be referred to as Stage.. 1 
of the production. In like manner, the dividing/rounding, 
oveirhoad proofer, molder and proofer machines are identified 
stage 2 . Stage 3 contains the oven, cooler and slicing and 
bagging machines. The definition of these three stages is 
also applicable to the two bun processes. A capacity unit 
in hours required to produce 10000 loans of bread and lOOOO 
packages of buns was found a convenient capacity measure to 
be used in formulating the machine capacity constraints. The 
capacity requirements of major stages of production is shown 



A-11 


in Table A-7 below. 


Table Kr-J'i Capacity Requirement in Hours per 10000 Units. 


Product 

Stage 1 

Stage 2 

Stage 3 

1,3 ]b. White Bread 

4.3 

1.2 

133 

1.3 lb. Wheat Bread 

4.3 

1.2 

2.0 

1 lb. '//hite Bread 

2.9 

1.2 

1.3 

Hot Dog Buns 

9.0 

2.6 

4.0 

Hamburger Buns 

11.2 

2.6 

4.2 

The times shown include 

the downtime 

allowance 

require' 


for maintenance, cleaning, change over from one kind of product 
to the other on each line loading and unloading activities. 

The capacities available for each line and each stage for a 
threC' shift work force is shown in Table A‘-8 below. 


Table A-8i 

Available Capacity for Each Line 

in Hours 

Product 

Stage 1 

Stage 2 

Stage 3 

Bread 

135 

153 

151 

Bun 

150 

135 

150 

Using above 

information the management wishes 

to 


determine the best product mix for the company. 

The LAMP formulation for the above product mix problem 
is given in Figure A.5 and Figure A.6. 



* " NOTE : Lines startma with are 'Comment' lines. 

* TERMINOLOGY PHASE 

» MOLECULE 

BREAD=X1 rX2»X3 

BUN-X4.X5 

STAGE=1.2.3 

* IHENTIFIER 

» UNIT PROFIT : ( Table A-6 ) 

PROF IT .BREAIiS 

FROF IT.BUNt 

» LA’^-AlITY PEOUIREMENT : < Table A-7 > 

RED.n EF.I .ST AGES 

REG'. BUR. STAGE 9 

» AVAILABLE CAPACITY : < Table A-8 > 

AVLE-REAI .STAGES*- 

AVLf.UN. STAGES* 

)» BOUNDS : 

UPBOUND.B'REAHt 
LOUBDUKD. BREAD* 

UPBa’JfJD.BUN* 

LOUliCUNI'.BUN* 


Fif. A. 5 


"Bakery Problem” Terminology Phase 
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4 I' NOTE : LiriP!, stertins with are 'Comment' lines. 

» F'KOFLEH STKUCTURE 

» OE.JECT1VE 

MAXI tKE-ADU-KOf IT .BREAritliKEAri-?! + CEUN:PR0FIT .BUNJEUNfD 

» r.OHCTKAlNIP 

» Cat Utilizetion for Bread 

SUMlI'FLAIi:REO.BRtAri.STA6F»BREAri'f: = AVLBREAIuSTAGE 

4 Utilization for Bun 

5 UM! E'JNrff a.FLl'..MA&EitBUK'!'3 - AULBUfJ.ETAGE 

» ci.i Brtcd pToductioii 

Efi.M' Vi iT.JU: .HIM 

4 Cr'ilins. on Bun F rodurtiori 

BUN'- Uf BOUNB.BUK 

4 MitiiB.ufM P'rodurtion of Bread 

BFvE All'’' = LOUBOUNIuBF.'EAD 
4 Mining jn Ft nductior. of Bun 

BUN'- - I CrCBDUHB.BUK 


Fig. A, Si "Bakery Problem" Model Structure 



lamp "HELP" PILE 


This docun.eni describes the ussse of the LAHP ( Larisuese 
Aided Methen.etical rrosTemnans ) sssten. based or* PASCAL 
lariSua^e ar*Q is csesbie of seneratins Linear Prosrsninans 
models ♦ 

The selient features of the ssjsten are: 

1* It IS interactive and user friend Is* le. the 
systen. issues niesssses with eruniet for reouared inf orn.at i on 
ssT>t ec 1 1 Cc 1 error arid eiiecutior. cor.tirrjes o'-.lt efleT 

accej^tcble inf or mat luri is su-^pliec* bs user in the desisned 
fOTRiat^So to sss that error correctior* is done then end 
there ♦The terniirisl fuessases with rroni^t are e.deGuate for 
inr ut erid e;u^ 3 airiat lori required to use the sssten.* 

2^ The ssTitaL of the sssten* isouite sinalat to 

alset'raic nciatiori to help the niodellei . 

3, Tiie three basic phases o'*' the niodsl d^velornent art 
Tern ir*cd osy> I'atabasc- ano Acs! reel n.ocel. 

A, It cCcfcf Ls declereiion o1 aDstiac*. f.ode- ir« tri.^is . 
ilia iansuasc arts devtZoFS the n.odel an slseb^aiv '^orm. 

5. Iderit if i ers cari be describeo an aost raci forn. usins- 

inolecules ( tern-s )-Tho sycT,ec. aenerates all possible 

cona'inei icris ari the pattern of cartesiar. rroouct ano issues 
pronir-t for etch identifie’^ oa-Ls value entry* 

1 oefit 1 f 1 e r 4 : for data v/a^-ues 

idenlifitrG : foi ider.ljfaeT v=iisblc- r.ame 

ideni j.-f J ■for deiCi ibins. loenti-Tier variable 
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Nosjii- u).ei car, »c for ii.teractivr ses-sioi, or 
dot« tiilru UF to tvt niinoloav and cfstabaaL t-liase 
IfncHjdi, fiie ar.d ucft with some LP bscV S round naa rrovidc 
j r.t c t n,., t i (111 I CT t u 1 ni ria }.o all the F^hates throuafi MIC tile. 

Ill the ah'.tract Hiociel de wt 1 of merit f-hase objective 
f u,,. *. Kill and wt.clc t'unch of conttrainti. are develoeed usins 
j.j« i.l ^ t n • .iiiu niulecijlet . ident itiers not defined earlier 

i w' i»f‘ fji!*, lt.ieo r«ow. 


t»u viFfifnjt itc.oj3es of the system eerforni the 
•» ‘ 3 »“W V i 3 u? <t «*■ aeserjbed below I 

: .In-h i, f I u: I t 

ItTmt: of Tc rmiriol os^' phrse* 

, .c HJt » Fnn r : 

t .hi ttTii for Men) £ a ri ty'-aris et ro^ ♦ 


I:'** :f c . t'H i 4 J. Tern.iric 3 d£s ehese . 


H.hi ;a. : 

hill di'CaiiOfi voTieble in etomic form, 

inltT! ctonu- iti lettc'^ sto^e. 


e .1 ? : 


i t ' : i< i M « i . 


McJtrdificr es type-d by user 


.bdibun : 

C;h<c)h ici the validity of identifier. 

ii.’AUbun : 

idifttififT used so decjsao • veTist'lc. 

".b i»/tiAibrN 7 : 

£.» to 3 deni 3 f It' T dots values as supplied b- 


M it. 



8 *r!DrHCCh 


B ^3 


Cl^c'cl 1* ider»tifier corriportenls with respect tv 

cieclcieo »Dlt.*culfc*v»* 

«^M»OCO«STK*A 1 NT : 

SP'l€‘cti affroFTistc procedure after chert irts 
t^^c c oaijt r ini t vJ" e for ado’s nsa furlhor constrosnife as 
dc* - *' hi' o' in fcfhi t T ft) c t f o rnu 

u *ii»£WTCHrrK : 

Chi*£l“ iht coiis:! roirii eouitior. idcrdifier 
riic-tch witr* f-hi-Sfr declored identifiers. 

Acccfto idfiitifier in sr-e'cial case'- ai 

1 U t i u h' Ut*i*T ♦ 

ir a»C 4 hhiDf : 

f TioT c^»ec^• of syritsn for cortslran.! 

i li i 1 ui » t V' i * 

1 i .F I AI'AHt : 

l« KHc e.\FTiS£iorj ^deritifiar cf 

f O I t ^ * i J »t i‘t i». t * 

lA.^ C'K. ‘d‘l : 

^ Ij.,y r,pitirt£ cotistTsml after vclidix-r 

( h i i* *’ -1 i f i ♦ * nc 1 4 ^ P T n 4 


:i ,i.hj :iVtn • 

CM'.iC'TctiS corisl Taint of bour»d “tyFo le* Xj 

hi 4 


It^StlflTYf I cor^s 1 


hc-ofe r ai t'i coristroints of 5 uruii.ation ty? ef le 

' li ii i C Xj • 


i o f n > . 


uoi- r • 


r^hih’COfNfb : 

coriStreinlE m ssners^ ej.s^pr.dud 

a 8 • 1 » 0 # 1 h 1 GE'W I 

s^tnc-Tilf-c eouatior, for vueusI B 3 d to 


IS .CCOrtSTi'IAMf : 

Accfeft< co-,dtr£ir,t for general 

L uni 1 1 i 1 ftt L 4 


? c rxocJxL 


A’TYF’ICONS t 

Gc-neiates sc-i,£T£ 3 £■ conatrsautE 

1 ,. ..stuff IE. 


which arc 



3 — £|. 


21*D0FILE : 

Ternanolofiy end database F>hase in^ut through 
separate external file* 

. 21. a DATAFILE ; 

Accepts the data values for separate 

external file. 

22. COMPRESS : 


blanks * 


Compresses the identifier name removins 


23.EQUhTI0NF0RM : 

Generates ej<rsr»ded eeuatiori form of model 
dev^e loped by LAMP* 

24*GrHPS : 


Generates external file <F1> hevins mode 3 
f orEjulat ion in industry standard MF'S fornist. 


MODEL DEdELGPMENT Algorithm : 


Step~l 


Step~2 


SteF’-3 


Declare Molecules* 

Declare Atonrs under each niolecules 
if any* 

Declare decision variable if other 
thoTi molecule * 


SteF--A • Declare required identifier and 
er.ter the values* 

SteT-'-Z . * Declare objective function and 
whole burich oY constraints ir? 
abstract form* 


SYNTAX for objective f ij.nctiori/coristrairrls J 


<REL1 could be <= or = dt >=• 
objective function 

MAX oT MIN Edvar I identifier t dvar'^l 


constraints 

fliolecule ? <REL> ideritifier 

SUH Z molecule * molecule ? 1 <REL> identifier 

SUM Z molecule 2 identifier niolecule; "r 3 <REL> ideritifier 

Example sessiofi I Product-Mix problem* 

1 . Declare Molecule : PRODUCTtCOMPNENT 

2 . Declare .Atons for eaebn if any I 

PRODUCT =Ph y PD y PC f PD t PE 

COMPNENT=R£SISTOR>CAPCJTOPyTFORhEFvnSPEAKEFxnlSlSTOR 


3*Declare decisiori variable ? if any 



4 ♦Declare identifier : 

REQ^PRODUCl ♦COMPNENTt 
PROFIT ♦PRODUC Tit 
INMENTRY^COHPNEHTS 
CEIlING*PRODUCTtt 


5 ♦Dec la re objective furiction and cortstrsint : 

M AX C PRODUCT : PROF I T'^ PRODUCTJ^PRODUCT? 1 

SUHCPRODUCTIREQ* PRODUCT ♦ COhPNENTJt PRaDUCT?l<=-I REENTRY ♦ COMPNENT 
PRODUCT'S^ <= CEILING,PRODUCT 


\ INPUT FILE CPP2 CONTENTS ARE GIVEN ♦♦♦♦♦• 


PR0DUCT=-PA f P& > PC ? PIi F PE 

COMPNENT=RES1STORf CAPC I TOR fTFORNERf SPEAKER fTSI STOP 
^ identifiers 

REG ♦ PRODUCT ♦ COMPNENTS 
PROFIT* PRODUCT $ 

INUENTRY ♦ COMPNENT$ 

CEILING. PRODUCTS 

objective function and constraints ♦*.♦♦ 

MAXC PRODUCT :PROriT*PROIiUCT3KPRODUCT?T 

SUNEPRODUCT :REQ -PRODUCT ♦COHF NENT3j:PROIiUCTT3 :: = I.WENTRY.COMPNENT 
PRODUCT? CEILING . PRODUCT 

iHf. identifier data values ♦,*♦* 

3.0 2.0 1.0 1.0 2.0 

4*0 3.0 1.0 1.0 3.0 

0*0 2.0 1.0 0.0 2.0 

3*0 2.0 1 .0 0.0 4.0 

5.0 ^.0 2.0 2.0 8.0 

2*0 4.0 8.0 6.0 2.0 

2000.0 ISOC.O 7G0.0 500.0 2250.0 
200,- 0 3 5C.C 50.0 400.0 500. 0 


f ACTUAL TERHINAL SESSION NOu FOLLOUS 


.£>: SR IP. PAS 
link: Losdins 

ELNKXCT SRIR executionD 

PLEASE TYPE IN ONE OF THE FOLLOWING: 

S :T0 give THE DATA BY YOURSELF IN THE INTERACTIVE HOBE. 

F :T0 take the input DATA FROK A FILE 
»F 

PLEASE TYPE IN THE NAME OF THE FILE (onls 10 chr width is permitted) 
»CPP2 

FILE NAME :CPP2 

YOU WANT TO ENTER BASIC HODULES :(Y/N) :Y 
PLEASE TYPE IN ANY ONE OF THE FOLLOWING FOR WHICH YOU WANT TO DECLARE: 

1 FOR FERNS'- 

2 FOR "ADDING SOHE HORE.' TERMS" 

3 FOR "ATOMS" 

4 FOR "ADDING SOME MORE ATOMS' 

5 FOR "IDENTIFIERS' 

6 FOR "CONSTRAINTS" 

7 FOR "OBJECTIVE FUNCTION" 

8 FOR "GENERAL TYPE C0NE1RA3NTS' 





THE DECLARATION IS DONE FOR IDENTIFIERS »» 

THE INPUT IS BEING READ FROM THE INPUT FILE :CF-pr 
PRODUCT 

PA 

PB 

PC 

PD 

PE 

COMPNENT 

RESISTOR 

CAFCITOR 

TFORMER 

SPEAKER 

TSISTOR 

YOU WANT TO GOTO OTHEIR HODULE OF MODEL (Y/N) : Y 
PLEASE TYPE IN ANY ONE OF THE FOLLOUIN6 FOR WHICH YOU WANT TO DECLARE: 
i FOR '’TERMS ^ 

2 FOR 'ADDING SOME MORE TERMS' 

3 FOR 'ATOMS' 

4 FOR 'ADDING SOME MORE ATOMS' 

0 FOR 'IDENTIFIERS' 

6 FOR 'CONSTRAINTS' 

7 FOR 'OBJECTIVE FUNCTIGN' 

S FOR 'GENERAL TYPE CONSTRAINTS' 

7 

THE DECALRATJON IS BEING DONE FOR THE OBJECTIVE FUNCTION 
YOU WANT TO DECLARE SPECIAL CONST RAI NT ( Y/N ): N 
PLEASE TYPE IN THE OBJECTIVE FUNCTION IN THE FOLLOWING WAY 
MAX/MINETERM2: IDENTIFIER)^>TERM02?3 

MAXEPRODUCT : PROFIT * PRODUCT )tiPRODUCT?3 

YOU WANT TO GOTO OTHER MODULE OF MODEL (Y/N) : Y 
PLEASE TYPE IN ANY ONE OF THE FOLLOWING FOf: WHICH YOU WANT TO DECLARE: 

1 FOR 'TERMS' 

2 FOR 'ADDING SOME MORE TEFvMS ' 

3 FOR 'ATOMS' 

4 FOR 'ADDING SOME MORE ATOMS' 

5 FOR 'IDENTIFIERS' 

6 FOF^ 'CONSTRAINTS' 

7 FOR 'OBJECTIVE FUNCTION' 

8 FOFv 'GENEFv-AL TYPE CONSTRAINTS' 

THL DECLARATION IS DONE FOR THE CONSTRAINTS 
YOU WANT TO DECLARE SPECIAL CONSTRAINT t Y/N ; J N 
PLEASE TYPE IN THE CONSTRAINT IN THE FOLLOWING FORMA'! 
SUMCTERM0:iDENTIFIER*TEKM02?I (<=) OR < = > OR <>= ) TERMJ^HS 
PUT ?? FOR NON-LINEAR TYPE CONSTRAINTS 
PUT > INPLACE OF 3 FOR RHS AS UAR'IAELE 

SUMCPRODUCI :RE0. PRODUCT .COMPNENT»^FRODUCT‘: 3<=3NUENTRY, COMPNENT 
YOU WANT TO DECLARE MORE CONSTRAINTS (Y/N) lY 
PLEASE TYPE IN THE CONSTRAINT IN THE FOLLOWING FORMAT 
SUMCTERMO; IDENTIFIERJtTERM02?3 <<=) OR < = > OF< <>=) TERMFiHS 
PUT ?7 FOR NON-LINEAR TYPE CONSTRAINTS 
PUT > INPLACE OF 3 FOR RHS AS VARIABLE 

PRODUCT?<=CE I L I NG . PR'ODUC T 

YOU WANT TO DECLAFJE MOR'E CONSTRAINTS (Y/K) TN 

YOU WANT TO GOTO OTHER MODULE OF MODEL (Y/N> IN 
YOU WANT TO ADD MORE CONSTRAINT DIRECTLY <Y/N) JN 


EXIT 



PRODUCT-MIX (INVENTORY) PROBLEM [131] a 

A manufacture of electronic equipment (equipment items 
A, B, C, D, and E) finds out that there are certain components 
in inventory that will not be used in the recently redesigned 
products to be produced next year. Thus the management 
desires these components to be used before the end of the 
year, in the current products, to the best profit advantage. 
Otherwise they must be shipped to subsidiary plant. The 
quantities of the components available in the inventory are 
shown in Table B-l. 

Table B-ls Available Components in Inventory 

Resistors Capacitors Transformers Speakers Transistor s 
2000 1800 750 500 2250 

Each product uses certain quantities of components left 
in the inventory as shown in Table B - 2 . 

Table B-2 » Components Utilization for Products, 


Product 

A 

B 

C 

D 

E 

Resistors 

3 

4 

- 

3 

5 

Capacitors 

2 

3 

2 

2 

6 

Transformers 

1 

1 

1 

1 

2 

Speakers 

1 

1 

- 

- 

2 

Transistors 

2 

3 

2 

4 

8 
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A consultation with sales department has indicated 
that atmost 200, 150, 50, 400 and 500 ijinits of products 
A, B, C, D and E respectively can be sold within the remain- 
ing months of the year. The maximum expected sales and unit 
profits for products are simimarized in Table B-3 . 


Table B-3 » Majcimum. Expected Sales and Unit Profits. 


Product 

A 

B 

C 

D 

E 

Maximum Sales 

200 

150 

50 

400 

500 

Unit Profit 

2 

4 

8 

6 

2 


In order to maximize the profit, how many of each of 
the five products should be produced so that as many electronic 
components as possible can be used from the inventory for 
production. 



APPENDIX C 

LAMP SYSTEM DOCUMENTATION 


The modelling language system LAMP (Language Aided 
Mathematical Programming) is based on PASCAL and is designed 
primarily for linear programming modelling situations. LAMP 
uses "molecule" and "ATOM" in place of set and set element 
used in the existing modelling languages. In LAMP, variable 
may be a 'MOLECULE" or an "IDENTIFIER" which may be scaler 
or arrays indexed over the molecules e.g, , "WATER* CROP, MONTH " 
to represent water required for a crop during a month. 

The modelling system LAMP has been built up using 
modular approach. In order to construct the complete formu- 
lation of a linear program, various modules of the LAMP system 
has been designed with subtask mentioned against them. The 
complete formulation is done in two phases viz. terminology 
phase and abstract model phase. In the terminology phase, 
moleciILes, atoms, concatenated identifiers and decision 
variables are defined which are used in the next abstract 
model development phase where objective and set of constraints 
are constructed for a particular linear program. 
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The various modules of LAMP arei 

(a) DOMOLECULEs This module defines the molecules of ter- 
minology phase and lists all of them after some preliminary 
checks, using "CHECK MODULE!' 

(h) CHECK MOLECULES This module checks the molecule name 
for any errors due to the typing and assists the "DOMOLECULE" 
module in having such validity checks. 

(c) DOATOMi This module defines the list of atoms or 
elements corresponding to each of the molecules defined ear- 
lier hy "DOMOLECULE" module and finally lists all the atoms 
for user verification. 

(d) PSETVARi This module defines the identifier type decision 
variable in atomic form using previously defined molecule 

and atom names. 

(e) ADDAT0M5 This module adds more atoms in specific situa- 
tions, if required i.e., in the case of special periodic type 
of constraint of abstract model. 

(f) READIDENT^ This module reads identifier as t37ped by 
user in some situation, if not defined or declared earlier 
during the terminology phase. 

(g) DOIDENT* This module has two sub-modules viz. , "DVARIDENT " 
and " DATAIDENT " . Depending upon the declaration i.e.s identi- 
fier name ending with "for "DVARIDENT" and " for "daTAIDENT , 
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made by user the particular sub-mod'ule is activated to fulfil 
the desired task after checking the validity of the identifier 
name with respect to declared molecule and atom names, using 
the module "DOCHECK", 

(i) DVARIDENTj This sub-module defines the particular 
identifier name as decision variable "DV'AR" and sets them in 
compressed atomic form using module "PSETVAR".. 

(ii) DATAIDENTs; This sub-module defines and sets the identi- 
fier data values as supplied by the user, during interactive 
session of modelling or through external file in batch 
operation. 

(h) DOCHECK» This module checks the validity of identifier 
components with respect to earlier declared molecule names. 

With above mentioned modules the |:erminology phase of 
model building is accomplished. Following are the modules 
that assist the user in construction of the abstract model 
phase of model building. Hereinafter "TERM" and "MOLECULE" 
are used interchangeably. 

(i) SPLCONSTs This module deals with special type of cons- 
traint situation where objective function or constraint is 
having two terms in its abstract form e.g,, expression or 
inequality in one of the following types accordingly. 
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MAX/MIN [TER]\10',IDENTIFIER*TERM02?] 

[ TERMOSS IDENTIFIERS ^ERM02S 
SUM[ TERMO I IDENTIFIER*TERM02 ?] + 

[ TERMOSS IDENTIFIERS*TERM02S ?] 

<=/=/>= TERMRHS 

MAX/MIN [ TERMO t IDENTIFIER*TERM02 ?] + 

ALPHA [TERMOS5. IDENTIFIERS *TERM02S?] 
SUM[TERM0sIDENTIFIER*TERI'102?] + 

ALPHA[ TERMOSa IDENTIFIERS*TERr402S ?] 

<=/=/>= TERMRHS 

The module ''SPLCONST" utilizes its sub-module " DOSPRIOR" 
for some prior analysis and structure (fomat) verification 
of the given special constraint and then develops associated 
objective or constraint (s) using modules "CONSSET" and 
"GENCONS For the objective or constraint structure having 
"ALPHA" in the abstract model form the user is required to 
provide the value for "ALPHA" at the time of execution. 

(j) DOCONSTRAINTs This module first checks for various 
structure of constraint type in abstract form i.e,, whether 
it is special, having two terms as described earlier in 
module "SPLCONST" or having single term. Then using "DOPRIOR’', 
this module does the prior analysis for determining exact 



C-5 


pattern of constraint type such as bound t 3 ^e, simple summa- 
tion type or general type, matching with only one term of 
pattern shown in module "SPLCONST"* Based on the result of 
prior analysis, it invokes either the module ’’DOBOUND " or 
"CONSSET" and "GENCONS ”, 

The various structures of possible constraint types 
should be as 

TERMO ?>=/=/> = TERMRHS for bound type 
SlM[TERMO;TERMO?] <=/=/>= TERMRHS 

for simple summation type 

SUM[TERM0iIDENTIFIER*TERM02?] <=/=/> = TERMRHS 

for general constraint type with 
single term only. 

(k) IDENTCHECKi This module takes the abstract form identifier 
and checks for its match with earlier declared identifiers 

and sets some indicator ( signal.) accordingly for specific use 
later. 

(l) SPIDENTS; This module accepts or defines a new identifier 
in special cases. Whenever an abstract form identifier is 
not found to match with already declared identifiers the 
system asks the user for its validity as new identifier. This 
also uses the modiile "IDENTCHECK" for verifying identifier 
components. 
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(m) UOPR'LORs This module makes prior check of syntax for 
abstract con str- tint in row-v;ise organization and after elimi" 
natj.n;' blanks, checks for all special characters which are 
us.fd as indicators for different constraint type determination, 
if required in some cases, it can provide nonlinear type cons- 
Lr.'dnt •ina]ysis and parameter value fixation by user. 

(n) ithADKHd; This module reads right hand side (RHS) identifi 
of abstr ct form constraint viz. "TERMRHS" and displays the 

on terminal for user verification. 

(o) tCkJ.USET: This module makes identifier component (part) 
m-*tch check with the decision variable of the given abstract 
fot'ni ctjnstr.'iint and uses module "IDENTCHECK" for identifier 
match v/ith .'ll ready declared identifier list and then depending 
upon thc' retjuirement , invokes modules READIDENl or SPfDENT 
.anti ' ItLADHiiS’* based on specific response* from the user. Hence 
ti.is modi ill 5.. ts thi.- v'.rious components of abstract form 
cu^nctr.'.int aftwr the v..lidity checks for associated variable, 
cocfi'icient Identifier, right hand side identifier (TERI*1RHS) 
.'ind GUmmation index (TERMO) are made. 

(p) DOiiOUiiDs This module generates simple bound type cons- 
trointn from the given abstract form 

TERMO •’<=/=»/> = TERiIRHS 

This module uses modules "IDENTCHECK" and READRHS for 
verification of '“TERMRHS" of given abstract form constraint 
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.iiKl rinaJiy writes the corresponding inequalities in e 3 <panded 
I'ortn. 


(.j) .‘liMTYi’KCoriSi This module 
/'T'lieraJ bound (upper or 

adr,trac:t roriu constraint as 


generates a constraint similar 
lower) type from the given 


;ibTl['.'EliMO;TERr^iO?] <=/=/>= TERMRHS 

(r) ''b'a’.bob'G.. This module uses the sub-module "GENllA-T ” which 
set;; the constraints in general expanded form. Using the 
ra.,i.lt;:, of modulf- "CObSSET" which checks the part (component) 
suefi.'sr.ivel y, it furthe-’ checks whether the abstract form 
•ajhstraint identifier matches v/ith the earlier declared 
id(;nt i l':i crs havinr, data values stored in the system. Later, 
using' an index function the proper coefficient values are 
rt.tricvid from thu array containing the data values for 
u.trticujar idc.-ntifier . Finally, based on "TERFIRHS" identifier 
nami th.’ constraint namc(s) is also set and stored in the 
syst^-m. This module uses "DOMATGEL" to write the matrix 
co-( fficionts. 


(s) DOiiATCiEh: This modulo writes the generated matrix 
coefficients for visual aid to user on terminal. 

(t) GCUH3TNAME: This module sets the name of the constraint 
as provided by user for the modelling situation using module 


"GEWTYPECONS'' doa} ing with periodic type constraint. 
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This module generates periodic constraints 
i onu f.c'riod lag component. This invokes module 

::Ai-iIs" for labelling various constraints. 


i, v) .A This module provides the facility of generating 

1; <• ! hic .r program model in batch mode for a professional 
'lacr, it' he opts for the same instead of interactive session. 

’''Uch mode modelling he should provide all the relevant 
ia ! tiou needed for model building in certain order through 
•' ■■■.I' c:<t., rna] file having entries as below. 

' .IuI,KCU[.El=AT0Ml,AT0M2, . , . 

, :iis (PrAjhTTOh , ONIOW , APPLE , ORANGE 


• iLL:.TIEIEK(S) 
WAVER. CROP. MONTH I 


»^AHS'1’RACT MODEL OBJECTIVE/CONSTRAINTS 
MAX[ CROP i PROFIT . CROE^ CROP ?] 

SI 1M[ CROP ; WATER. CROP . MONTH*CROP ?] < = WATExRAVL . MONTH 


# IDENTFIER DATA VALUES IN SAME ORDER OF IDENTIFIER 
Ob.O 


# # # # 
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Thu;: uainf; sub-module ''DATAFILE’' this module accepts 
input throui'li an external file for molecules, atoms and 
;i .firuT,. Further this module alongv/ith command file 
and the sarno external file having information for ohj active 
arifi uon:,;traints in abstract form completes the modelling of 
1 in«?ar pro,*' rain based on information constrained in the above 
i.i'/n tloncd fiJ.os, 

(v;) This module generates the entire model 

I'oiTiul atior as linear program in expanded form. The whole 
b'unch oj’ fpjnstraints alongwith objective function at the top 
n.!' it ii; v/ritten on a separate file named "F2 " which can be 
uli'liztd I'tirthuT by any problem processor for obtaining 
sfdutlon:; to linear program. The problem processor used in 
our oa:;. i;: LIL'DO [1^^^]. Further as LINDO does not accept 

mor; bhai'i If/P characters for input in a line in the form of 
ohjoctiv. .function as well as constraints, the same has been 
imi 'lumen ted as a specific requirement, which need not be so 
in f'.fnvra'l. 

(x) OFKPS; This module generates the model formulation in 
industry istandard DIPS format [92 ] acceptable to most of the 
C'xisting problem processors e.g., LIMDO and others. By 
iiivoking this module, the model formulation of linear program 
is written in I-IPS format on a separate file named “Fl" which 
can be utilized further by any problem processor for obtaining 
solutions of the modelled linear program. 
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Thus the major task of model formulation is achieved 
by the above mentioned modules. However, some small modules 
also assist in accomplishing the above task viz. , 


PREAD ; 
PWRITE ; 
PLNREAD ; 
COMPRESS ; 


It reads a character from the terminal. 

It displays a character on the terminal. 

It reads a character from a new lino. 

It compresses the identifier name after removing 
the blanks. 


Apart from the above, LAl'-TP can also generate model 
formulation for transportation and assignment problem by 
invoking modules "TRM^SPORT" and "ASSIGNMENT” respectively 
in standtird formulation pattern. 
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LIKTEAR INTERACTIVE AI'ID DISCRETE OPTIMIZER LINDO 


LINDO (Linear Interactive and Discrete Optimizer) is 
an interactive linear, quadratic and integer programming 
modelling language system developed by Linus Schrage at 
Graduate School of Business, University of Chicago, USA. It 
is a small scale system designed to be useful to a variety 
of users. The major design consideration has been that if a 
(potential) user wants to do something simple, then tine re 
should not be a large set-up cost to learn the necessary 
features of modelling language system LINDO, LINDO has been 
in use since 1981 for solving real industrial linear, quadrat; 
and integer programs of respectable size* Several versions 
of LINDO have been implemented on main frame, mini and micro 
computers of different computer manuf^^ctures viz. DEC, IBM, 
Datr Gonornl, Honeywell, Burroughs, CDC, HP, Univac, etc. 
on DEC-20 computers it is typically configured to solve 
problems with upto 800 rows and 4500 variables. This capabilit 
is generally increasing with each new version of LIInIDO, It is : 
biased towards the user who is interested in developing and 
solving formulation of real life problems from diverse fields 
of military, industries, agriculture, trexLsportation and 
service sectors. 



LINDO is designed for interactive computing. However, 
it can be run in batch mode with no modification through 
external file on a batch system. LINDO is command oriented 
rather than menu oriented. Thus it does not restrict any 
user to go through fixed sequence of steps allowing only 
small options along the way. User can select from wide range 
of commands in any order as per his specific modelling 
requirement. It can be run in a conversational style. 
Introductory help about the system features are provided by 
HiELP", "CATAGORIES" and "COMMANDS" commands. Using them 
user can get the list of all commands available, which are 
grouped into categories according to use e.g., input, output, 
etc. Then using ’’HELP " followed by any command name he can g< 
the detailed information of specified command. 

LIMDO user can divert the solution and modal formula- 
tion of real life problem to a designated external file. 

LINDO has file output commands for two purposes* 

. Store a problem formulation", 

. Store the results of computation. 

User can provide model input to LINDO through external 
files which may h''ve input information either in industry 
stiind'^-rd MPS format or in expanded inequality form. LINDO 
has specific commands for taking input from files. The MPS 
format for describing an LP is widely accepted industry forma 
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The MPS format has from three to five sections^ "ROWS" 
"COLMS", "RHS", "BOUNDS", "RANGES". "BOmmS" and "RAIMGES" 
are optional. 

The "ROWS" section lists the row names, one per line, 
with the name preceded by its type. An "L" means (< =), 
an "E" means (=), a "G" means (>=) and an "N" means not 
constrained (e.g., the objective function row). 

The “’COLUMNS" section lists each non-zero element of 
the matrix preceded by the column name and row name in which 
it appears. 

The "RHS" section lists each non-zero right-hand- side 
element preceded by the name of the row in which it appears. 
One must also give a name to the right-hand- side i.o., "RHS". 

In MPS file form of input it is allowed to have severa 
non-constrained rows i.e., multiple objectives can be listed 
by assigning "N" alongwith particular row name having objecti' 
function. The system asks user to indicate the particular 
objective function to solve the model formulation through 
fiven MPS file alongwith the information regarding maximiza- 
tion or minimization. 

LINDO provides an elegant problem summary (e.g., numbe; 
of rows, number of variables, number of integer variables, 
number of non-zoro elements, number of non-zero constraints. 


matrix density, smallest and largest element in absolute 
value, number of less than equal to constraints, number of 
equal to constraints, number of greater than equal to cons- 
traints, objective function, number of generalized upper 
bounds, etc.). This summary is quite useful for model 
ana3.ysis of large problems. Model validation before solution 
is an essential task for a large size linear program. In 
the case of large linear program model the variables may 
be misspelt, the sign of coefficient may be wrong, the 
coefficient may bo in wrong constraint, the coefficient may 
be associated with wrong variable, the decimal point may be 
misplaced. Such errors may lead to absolutely erroneous 
solution which necessarily have to be eliminated before 
model being run for solution. In this context model analysis 
capability of LIIIDO in the form of problem summary is commend- 
able. 

LINDO is quite useful for mathematicians as it is 
capable of providing several analysis of working of Simplex 
method. LINDO uses Revised Simplex Method. Various commands 
allow user/ analyst to study the mechanics of the Simplex 
method for solving linear programs. One may optionally 
include a variable name after the word pivot, e.g., "PIVOT 
COTTON", in which case the named variable (e.g, , "COTTON" in 
this case) is made to enter the solution. One may optionally 



include a row number after the variable, in which case the 
pivot will be made in the specified row. LINDO has the 
features for the mathematician who may be interested in 
displays of the tableau and some other steps of Simplex 
method. Specific commands in LlhDO provide insight into 
the workings of the revised Simplex method, "IInIVERT " command 
roinverts the current basis i.e., it re-solves the set of 
simultaneous linear equations implied by current basis. The 
inverse is represented by product of elementary matrices 
(i.e., identity matrix except for one column). Inversion 
trif‘S to permute the rows and columns of the basis so that 
the matrix is as close to the triangular as possible because 
a triangular system of equations is easily solved by back 
substitution. 

In order to study the effect of various parameters on 
the optimal solution, LINDO provides specific commands. The 
"RAiMGL" command causes a standard range report to be printed. 
This report specifics the allowable changes for objective 
function and right-hand- side coefficients which will not 
cause’ a change in basis. LIIMDO allows for sensitivity 
an.'ilysis also. 

LINDO has a quadratic programming capability which 
allows the us^-r to consider problems with a quadratic 
objective function i.e., objectives which contain the 



pr'ocJuct of few variables. Users in general be interested 
in whether tJie optimiam found by the quadratic program (QCP) 
algo2’ithm is global optimum or simply a local optimum. If 
the submatrix corresponding to the quadratic part satisfies 
certain conditions then the solution found will be global- 
optimum. One condition sufficient to guarantee global 
optimality is positive definiteness- 

LIWDO allows variables to be integer. It can be 
general integer variable or zero/one variables. General 
integer variables are' identified by specific command. LIMDO 
uses branch-and-bound method for solution of integer programs. 

UNDO contains a dummy subroutine called "USER". This 
allows a user to do a variety of things, such as write a 
sp'-'Cial purpose input/output procedure or incorporate LINDO 
into larger systems. 
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UNIFY RELATIONAL DBMS SOFTWARE 


"UNIiY" is a relational database management system 
software developed and supplied for commercial use by UNIFY 
Corporation, Portland, Oregon, USA. "UNIFY" is based on 
"UNIX"' operating system. UNIFY is a collection of over twenty 
different programs, all integrated together to let user create 
and modify application systems that store and retrieve data. 
The UNIFY System is menu driven. The primary user interface 
to UNIFY system is the menu handler (MENUH) . The menu 
handler provides the means to let user select any UNIFY 
program he wants, as well as controlling security, so that 
he can deny access to certain programs. This menu handler 
is linked directly with set of utilities viz., "SQL", "Query 
By Forms", "Enter ", "Database Utilities", "Host Language 
Interface" . All these utilities are directly linked with 
"Unitrieve Data Base Kernel" which is linked with "Data 
Dictionary" and "Data Base Volumes". Report writer is 
linkc.'d to "SQL," and "Query By Forms". UNIFY is provided with 
a sot of built-in mtnus ready for user to use in developing 
his application. However, he can also create his own menus. 



In order to exiJloit the DBMS capabilities fully the system 
menu provides following options ^ schema maintenance, schema 
listing, create data base, " SFORM" menu, "ENTER" screen 
registration, "SQL"- Query/DML language, "SQL" screen regis- 
tration, listing processor, data base test driver, "MENUH" 
screen menu, "I'ffiNUH" report menu, reconfigure database, 
write data base backup, read data base back-up, data base 
maintenance menu. 

The UNIFY non procedural query and update language 
is an implementation of the IBM-standard structured Query 
Language (SQL). Using SQL, user can interactively add, modify, 
del etc and query information in his data-base. Moreover the 
user can connect a screen form to an SQL query script and 
then format the results of the query with the primary UNIFY 
report writer, "RPT This interface is usually called SQL 
By Forms . For performing thc’ simpler queries that are often 
more than half of the queries performed, UNIFY offers Query 
Forms (OBF). QBF lets user fill in search values on a 
screen form, v/hich is used to find the records that match. 

User can look at them one at a time on the screen form or 
h c-in Send the results to one of the UNIFY report writers'. 

'RPT " which is powerful, listing processor "LST" which is easy 
to use. 

Full screen data entry is handled by the utility 
"ENTER''. ENTER performs many kinds of edit checks including 



type, length, date and time formats, amount formats, and 
table look-up. In addition, user can add his own fimctions 
to customize it further. E3MTER uses the screen foras 
that can be created and modified using the SFORM utilities. 

The utilities necessary to create and maintain a 
database include: programs to enter and modify the database 
design (i.e., schema design)*, create and reconfigure the 
database, maintain field level securily; print statistics, 
read and write back-up tapes (or floppies) j repair corrupted 
data bases-, and load in data from ASCII files. The remaining 
part of the structure are internal to the system. Although 
operations of Ul^IFY requires little or no knowledge of UNIX 
or programming, having some background of above is quite 
usefxJl. 

The transaction logging and console monitor utilities 
make the operation of application system easier and more 
reliable by recording all databast' updates and displaying 
menus for user guidance respectively. 

In order to use* UNIFY DBMS Software for the applica- 
tion, user first creates and maintains the schema and the 
database itself using data base maintenance utilities. Then 
using the screen fonii... tool SFOHl''! data could be entered in 
the data-base. The general purpose data entry progrem -'ENTER" 
can be used to drivc' SFORM Screens. 
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Once the data has been entered In the data base, 
the UNIFY SQL and RPT processors can be used to retrieve 
data or presc-^nt it in a meaningful format* The H'flFY query 
lan|>;uage, SQL, is a powerful subset of the IBM standard 
relational query and data manipulation language, SEQUEL 2. 
Besides SQL, UNIFY also has a simpler, less powerful query 
interface designed to do file listings with totals and 
subtotals. This program is called listing processor (LST). 

UNIFY can be used as the SHELL, The main shell 
commands aroi 

DBLOAD i This permits loading of data into database from 
an ASCII file. 

LST : This allows producing simple sorted file listings 
with totals and subtotals. 

RPT ; This allovre producing sophisticated reports using 
a powerful, non-procedxxral language. 

SQL ; This allows query and update of a database file 
using powerful, non-procc dural language. 

The UNIFY’ s specific fo^-^tures of schema design is 
described below. 

The " UNITRIEVE " data base is set-up and maintained by 
dosignin/', interactive schema for appropriate records and 
their fields using the relational approach. The schema entry 
program uses two screen forms, first for general record 



information (e,g., Line Number - LN, Command tCMD, Record 
name - RECORD, Expected numbers, Long name - LONG NAME and 
Description) and the second for detailed field information 
for the record created earlier. 

The various user assistance prompts of paging area 

arei 

n - displays next page of data base record type. 

p - displays previous page of data base record type. 

a - permits adding of new data base record type. 

The various command area options aroi 

f - modify the fields for current record type. 

m - modify, expected, long name and description for 
the curri.nt record. 

d - delete current information (record). 

q - redisplay the paging prompt at the bottom of 
the screen. 

Some of the restrictiors on the record and field details 
are as follov/si 

A record can bo given a name of maximum eight charac- 
ters having upper and lower case letters., numbers and under 
score character (__) beginning with letter only. Long name upto 
sixt.. ■n character length with other feittures similar as record 
name can be given which is used by "ENTER", "SQL" utilities. 



Description can be used as "Comment" field for description 
of record. 

The field information (e.g., Line nximber “ LN, 

Comm.and -CMD, field name - FIELD, Key - KEY, Reference ~ REF, 
Type - TYPE, Length - LEN, Long name - LONG NAME and Combi- 
nation Field - COMB) can be set for any record using prompt 
"f" in the command area of record schema maintenance. "Field 
name" has the same feature as that of record name. Asterisk 
(x-) is the entry to be made in the "KEY" column to indicate a 
particular field to be treated as key field. 

"REF" column is used to establish an e^qDlicit relation- 
ship with another record type (i, e. , linking with some base 
field.) The "TYPE" column is used to indicate the different 
data types associated with the field using first character 
as follows: "n" for "NUMERIC;' "f" for "B^LOAT "/'S " for ''''STRING',' 
"d" for "DATE*; "t" for "TIME',' "a" for "AMOUNT" and "c" for 
Combination (COMB). 

The "LEN" column represents the entry for the length 
of the various fields for display. If not provided by the 
user at schema design the system assumes some default values. 
"LEN" has the form "nnd" for float field (i.e., 179 represents 
17 display positions having 9 positions for decimal values). 
"COMB" field column is the unique feature of UNIFY system 
that it allov/s user to specify multiple fields as key of the 
record type (rtlation). 



The " LOWCi NAME" column is used to give long field 
names (upto sixteen characters). The regular field name 
is valid upto eight characters. The long field names do not 
have to be unique for the whole data base, but the regular 
field names must be. Field names must begin with letter and 
comprise of letters, digits and under-score character (__) 
having no blanks in between. In case of same long field 
name in different record types the particular field name is 
referred by prefixing the record type name to the long field 
nam»_ (i.e., iconsn.cons_id or imat.cons_id) , 

The "C0r4BINATl0N" column is used to specify multiple 
field key, if any. 

The so features arc used to create and maintain schema 
in a systematic way. The "RETURN" key on terminal is used 
for forward reference and "CTRL" key along with "U" key is 
used for backward reference alongwith specific options 
selected on the display terminal during the UI\lIFY system 
operation. 



APPENDIX F 


STRUCTURED QUERY LANGUAGE 


The Structured Query Language (SQL) was developed at 
the IBM Research Center as a relational inquiry and data 
manipulation language based on English Keyword Syntax. Its 
structure was refined through extensive testing to produce a 
language easy enough for non specialists to use, yet powerful 
enough for data processing professionals. SQL is fast 
emerging as the standard relational query language on variety 
of computers starting from main frame to micros. The UNIFY 
implementation of SQL, is primarily based on the language 
desCi''iption [38], In order to adapt it to supsr^microq/ 
minis and the Ul'JIX environment some changes have been made 
to the syntax. Most of the query and data manipulation 
features have been implemented without modification and 
UNIFY’ s SQL is claimed to be the most powerful relational 
data manipulation language available on supermicros. 

SQL is a powerful, English keyword based language that 
lots user specify queries of varying degrees of complexity, 

A query consists of phrases (also called clauses), each 
of which is proceeded by a keyword. 
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These keywords are: 


and 

asc 

avg 

between 

by 

count 

delete 

desc 

edit 

end 

fields 

from 

group 

having 

help 

in 

insert 

into 

is 

lines 

max 

min 

not 

or 

order 

records 

restart 

select 

separator 

set 

start 

sum 

unique 

unlock 

update 

v/here 

The required phrases (clauses) areS 


select - 

Some data (a 

list of field 

names) 

from 

Some place ( 

a list of record types) 

The optional phrases are 



where - 

a condition 

(a true/false 

statement) 


group by — som..' data (a list of field names) 
having - a group condition (a true/false statement) 
order by - some* data (a list of field names) 
into - a file name. 

The relations (record types) and fields to he used in 
selection and calculation are identified by the relation 
names and long field names (maximum of sixteen characters) 
from the UNIFY schema design for the database. Schema design 
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of UNIFY permits both regular short names (upto eight 
characters) and long names (upto sixteen characters) for 
naming of the fields. Long field names donot have to be 
unique for the whole data base; but the regular field names 
must be. In case of same long field names in different 
rc‘lations the specific field name qualification is done by 
prefixing the relation names. Valid field names should begin 
with letter only and comprise of letters, digits and under 
score character (_) having no blanks in-between. 

SQL allows fre.' form input - line can bo spaced across/ 
many statement clauses can be compressed in a line. This 
moans that extra spaces and carriage returns may be used 
freely to improve the readability of a query statement, without 
changing its me.aning. A query is ended by the slash character 
(/), at v/hich time- SQL begins the evaluation of what user has 
typed. If the user entered a valid query, the message in 
response to slash character is "recognised query". If the 
query had some syntox error and SQL was unable to understand 
the user query, on error message is displayed on the termi- 
nal that gives user an idea as to what kind of error was 
me.du by him in writing the query statement. 

UNIFY’ s SQL piovides three kinds of help that makes 
learning: and using SQL easier. User can get help about 
genera} syntax, any specific keyword, keyword clauses or 
the valid field names for the data base. 
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The simplest kind of SQL query includes both a "select" 
clause and a "from" clause. The "select" clause lists the 
i'ields to be printed, while the "from" clause tells which 
record type (s) or relation (s) the fields are to come from. 

As user rarely wants to list the entire contents of a record 
type (relation), the "where" clause is provided to let user 
specify selection criteria. The "where" clause lets user 
compare a fi: Id with a constant, an expression, or the results 
of another "select" clause. The "where" clause can also con- 
tain a complex boolean expression composed of selection 
criteria connected by "and"/ "or" operators. Precedence can 
be estab] isho'd by use of square brackets. 

Arithmetic expressions are provided to let the user 
calculate values using the standard operators +, and 

/. Both constants and fields may be used in arithmetic 
expressions, which are allowed on fields of all types except 
string and combination. Arithmetic may be used wherever a 
simple field is allowed in "select" , "where" and "having" 
clauses. 

SQL provides five different built-in aggregate functions 
to allow calculation of aggregate items in a query result. 

The functions are "count (-■) ", "rain", "max", 'sum" and "avg" . 


Aggregate functions arc only valid v/hen used in "select" or 
"having" clauses. User may not use an aggregate function 
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directly in a "where" clause, although using nested query 
he can usually achieve the same effect. As natural, an 
aggregate function only applies to a group of records with 
a common characteristic. The "group by" clause is provided 
to allow computation of aggregate function on group of 
records that have common characteristics. Thus using a 
"group by" clause without an aggregate function has no 
meaning. The effect of a "group by" clause is to sort the 
selected rows by the indicated fields, ond then perform 
the aggregate functions at each level break. Tho output 
results are sorted also. 

Nested queries allow user to get answer for a whole 
new set of questions that cannot be answered using the 
capabilities of SQL presented so far. Nesting allows user 
to use tho results of one query as input to another. Thus 
he can use the results of one question in answering another 
one, for example, checking simple upper bound situation in 
our relational database for linear programming modal as belows 

Select iconsn, cons__id, consjaame 
from iconsn, imat 

where iraat.cbns__id = iconsn. cons_id and iconsn, cons__id^'^ = 
Select imat.cons_id 
from imat 

where imat .mat_olement-''^ = 1* 
grouT) by iconsn. cons_id 
having sum (imat. mat element) = 1/ 



F-6 


Queries can be nested to any level and evaluation 
takes place from innermost to outermost block in order. 

Nested queries can be used in both "where" and "having" 
clauses at the same time. 

The "having" clause lets the user select some of the 
groups formed by a previous ’’group by" clause and reoect others 
based on the results of another selection using one or more 
of the aggregate function. This gives user a capability 
equivalent to using an aggregate function in a "where" clause, 
which is not allowed otherwise. 

Thu "order by" clause lets the user sort the output 
of a query. He can specify ascending or descending sorts on 
each field, or can omit the specification entirely. In such 
situations, the default sort order is ascending, with "STRING" 
fic'lds sorted in alphabetic order from A to Z. 

SQL may list fields from any number of record typos 
(relations) in a single query. Queries that list fields from 
several record types arc called .join queries, because they 
join the different r cord typos together. The different record 
types (relations) to b^^ involved .in the query arc listed in 
the "Jrom" clause, in any convenient order. SQL then determines 
what is the most efficient method of performing the selection 
and qualification. The fundamental concept underlying join 
queries is thait of Cartesian product. Conceptually, a 
join query first forms thu Cartesian product of the 
record tyr)es (relations) and then "filters" the result 
by the conditions in the "where" clause. 



Thus a join query without a "where" clause does in fact list 
the Cartesian product of the record type. Sometimes it is 
necessary to join a record type (relation) with itself. 

Rea'ular nested queries work " from the inside out "^ 
evaluating the innermost query and passing the ros^ilting value 
or values back out to the next outer query. Each query is 
performed only once. Variable queries reverse this proce- 
dure, working " from the outside in" . This lets the user per- 
form an inner query multiple times using values from the outer 
query. As the inner query varies depending on the record type 
(relation) in the outer query, this kind of quory is called 
3-s variable query . ITic inner query to be performed multiple 
times is ended with a semicolon (?) instead of ending the 
query with a slash character (/). 

In addition to above stated query facilities, SQL 
also provides data manipulation capabilities. This means 
user can interactively inser t, modify and delete records in 
his database using a high-level, nonprocedural language. 

There is also an interface to the UhlFY database load pro- 
gram "JJliLOAD", so user can load a database quickly from 
regular ASCII files. All of the query features of the lan- 
guage are retainorl Hmcc the user can use regular query 
statements to insert data from existing files containing 
record type-s into other files, and select records to be 
modified or deleted. Mien a set of records is specified to 
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be modified, that set is locked using the UNIX file locking 
system calls. This prevents severed users from simiiLtaneously 
trying to modify (update) the same records. 

Tho "insert" clause allows the user to add new records 
to tho database, using constant v^ilue or values returned as 
the result of a query. Only tne primary key value must be 
specified. Other field values that are not sp'^cified are set 
to tho standuj'd.^ initial values - zeros for " NUI-IERIC ", "FLOAT", 
"AI'IOUNT", "TIME" and "STRING" fields and null (-32768) for 
"DATE" fields. Besides using literal tuples, an "insert" 
clause can use thr results of a qeiery statement to obtain its 
values. 

The "ui^date" clause lets the user modify fields in 
existing records. Updates can be specified with litoral values, 
expressions or query statements. ii"wberc" clause to specify 
which records the update applies to is not required. If it 
is left out, tht: update is applied to all records of tho 
indicated type. A field can be updated using an expression, 
and more than one field can be changed in a single update 
clause. 

The "delete" clause lets the user delete records from 
an existing file (n-cord type). The records to be deleted 
are identified by a "where" clause or if this is not present, 
all tho records for thr> indicated t 3 q>e are deleted. 



in addition to above mentioned facilities, UNIFY^s SQL 
oT'ov i-ier. r>f=veral extensions to the basic language for inter- 
ned; ive query development in the UNIX environment, which makes 
it pov;eri’nl. 



